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本 书 从 几 个 维度 介绍 了 React。 一 是 作为 View 库 ， 它 怎么 实现 组 件 化 ， 以 及 它 背 


扩展 到 Flux 应 用 架构 及 重要 的 衍生 品 Redux， 它 们 怎么 与 React 结合 做 应 用 开发 。 
的 碰撞 产生 的 一 些 思考 。 四 是 讲述 它 在 可 视 化 方面 的 优势 与 劣势 。 
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React 是 目前 前 端 工程 化 最 前 沿 的 技术 。2004 年 Gmail 的 推出 ， 让 大 家 猛然 发 现 ， 单 页 应 用 
的 互动 也 可 以 如 此 流畅 。2010 年 ， 前 端 单 页 应 用 框架 接 中 而 至 ，Backbone、Knockout、Angular， 
各 领 风 骚 。2013 年 ，React 横 空 出 世 ， 独 树 一 帜 : 单 向 绑 定 、 声 明 式 UI， 大 大 简化 了 大 型 应 用 的 
构建 。Strikingly 接触 到 React 之 后 不 入， 就 开始 用 React 重 构 前 端 。 

当时 我 想 , 2013 年 或 许 会 因为 React 的 出 现 , 成 为 前 端 社区 的 分 水 岭 , 今天 回 看 , 确实 如 此 。 

二 良 置疑 ，React 已 经 是 前 端 社区 里 程 碑 式 的 技术 。React 及 其 生态 圈 不 断 提 出 前 端 工程 化 解 
决 方案 ， 引 | 领 潮流 。 在 过 去 一 两 年 里 ，React 也 是 各 种 技术 交流 分 享 会 里 炙手可热 的 议题 。 

React 之 所 以 流行 ， 在 于 它 平 衡 了 函数 式 编程 的 约束 与 工程 师 的 实用 主义 。 

React 从 函数 式 编程 社区 中 借鉴 了 许多 约定 : 把 DOM 当成 纯 函 数 ， 不 仅 免 去 了 烦琐 的 手动 
DOM 操作 ， 还 开启 了 多 平台 演 染 的 美丽 新 世界 ; 在 此 之 上 ，React 社区 进一步 强调 不 可 变性 
(immutability ) 和 单 向 数据 流 。 这 几 个 约定 将 原本 很 复杂 的 程序 化 简 ， 加 强 了 程序 的 可 预测 性 。 

React 也 有 实用 主义 的 一 面 ， 它 不 强迫 工程 师 只 用 观 数 式 ， 而 是 提供 了 简单 粗暴 的 手段 , 方 
便 你 实现 各 种 功能 一 一 想 直接 操作 DOM 也 可 以 ， 想 双向 绑 定 也 没 问题 。 函 数 式 约定 搭 配 实 用 主 
义 ， 让 我 不 禁 想 起 Facebook 一 直 倡导 的 黑客 之 道 : Done is better than perfect。 

React 还 是 一 门 年 轻 的 技术 ， 网 上 能 学 习 的 材料 也 比较 零散 。 本 书 由 浅 到 次 ， 手 把 手 地 带领 
读者 了 解 React 核心 思想 和 实现 机 制 。 因 为 React 受到 了 很 多 关注 ， 社 区 里 出 现 了 各 种 建立 大 型 
React 应 用 的 方案 。 本 书 总 结 了 目前 社区 里 的 最 佳 实践 ， 方 便 读者 立刻 在 实战 中 使 用 。 














































































































郭 达 峰 
Strikingly 联合 创始 人 及 CTO 
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前 端 高 速 发 展 十 余年 ,我 们 看 到 了 浏览 器 厂商 的 竞争 ， 经 历 了 标准 库 的 竞争 ,也 经 历 了 短 短 
几 年 ECMAScript 标准 的 迭代 。 到 今天 ，JavaScript 以 完全 不 同 的 方式 呈现 出 来 。 

这 是 最 好 的 时 代 ， 这 是 最 坏 的 时 代 ， 这 是 智慧 的 时 代 ， 这 是 思春 的 时 代 ; 这 是 信仰 的 时 期 ， 
这 是 怀疑 的 时 期 ; 这 是 光明 的 季节 ， 这 是 黑暗 的 季节 ; 这 是 希望 之 春 ， 这 是 失望 之 冬 。 

这 是 对 前 端 发 展 这 些 年 最 恰当 的 概括 。 整 个 互联 网 应 用 经 历 了 从 轻 客 户 端 到 富 客 户 端的 变 
化 ,前 端 应 用 的 规模 变 得 越 来 越 大 ， 交 互 越 来 越 复 杂 。 在 近 几 年 ,前 端 工程 用 简单 的 方法 库 已 经 
不 能 维系 应 用 的 复杂 度 ， 需 要 使 用 一 种 框架 的 思想 去 构建 应 用 。 因 此 ,我们 看 到 MVC 、MVVM 
这 些 B/S 或 C/S 中 常见 的 分 层 模型 都 出 现在 前 端 开发 的 过 程 中 。 与 其 说 不 断 在 创新 ， 还 不 如 说 前 
端 在 学 习 之 前 应 用 端 已 经 积累 下 来 的 浑厚 体系 。 

在 发 展 的 过 程 中 ， 出 现 了 大 量 优秀 的 框架 ， 比 如 Backbone、Angular、Knockout、Ember 这 
些 框架 大 都 应 用 了 MV* 的 理念 ， 把 数据 与 视图 分 离 。 而 就 在 这 样 纷繁 复杂 的 时 期 ，2013 年 
Facebook 发 布 了 名 为 React 的 前 端 库 。 


从 表现 上 看 ,React 被 大 部 分 人 理解 成 View 库 。 然 而 , 从 它 的 功能 上 看 , 它 远 远 复 杂 于 View 
的 承载 。 它 的 出 现 可 以 说 是 灵光 一 现 , 我 记得 曾经 有 人 说 过 ，Facebook 发 布 的 技术 产品 总 是 包含 
伟大 的 思想 。 的 确 ， 从 此 ，Virtual DOM 、 服 务 端 泻 染 ， 甚 至 powernative apps， 这 些 概念 开始 引 
发 一 轮 新 的 思考 。 


从 官方 描述 中 ,创造 React 是 为 了 构建 随 着 时 间 数 据 不 断 变 化 的 大 规模 应 用 程序 。 正 如 它 的 
描述 一 样 ，React 结合 了 效率 不 低 的 Virtual DOM 泻 染 技 术 ， 让 构建 可 组 合 的 组 件 的 思路 可 行 。 
我 们 只 要 关注 组 件 自身 的 逻辑 、 复 用 及 测试 ， 就 可 以 把 大 型 应 用 程序 玩 得 游 力 有 余 。 

在 0.13 版 本 之 后 ，React 也 慢 慢 趋 于 稳定 ， 越 来 越 多 的 前 端 工程 师 愿 意 选择 它 作 为 应 用 开 
发 的 首选 ， 国 内 也 有 很 多 应 用 开始 用 它 作 为 主 架 构 的 核心 库 。 

在 未 来 ，React 必然 不 过 是 一 块 小 石头 沉 和 水底， 但 它 溅 起 的 涟 涝 影响 了 无 数 的 前 端 开 发 的 
思维 ， 影 响 了 无 数 应 用 的 构建 。 对 于 它 来 说 ， 这 些 就 是 它 的 成 就 。 成 就 JavaScript 的 繁 来 ， 成 就 
前 端 标准 更 快 地 推进 。 





































































































































































































本 书目 的 
本 书 希 望 从 实践 起 步 ， 以 深刻 的 角度 去 解读 React 这 个 库 给 前 端 界 带 来 的 革命 性 变化 。 
目前 , 不 论 在 国内 , 还 是 在 国外 , 已 经 有 一 些 人 门 的 React 图 书 ,， 它们 大 多 在 介绍 基本 概念 ， 
那些 内 容 可 以 让 你 方便 地 进入 React 世界 。 但 本 书 除 了 详细 阐述 基本 概念 外 ， 还 会 帮助 你 从 了 解 
React 到 熟悉 其 原理 ， 从 探索 Flux 应 用 架构 的 思想 到 精通 Redux 应 用 架构 ， 帮 助 你 思考 React 给 
前 端 界 带 来 的 价值 。React 今天 是 一 种 思想 ,希望 通过 解读 它 ， 能 够 让 读者 有 自学 的 能 力 。 



























































阅读 建议 
本 书 从 几 个 维度 介绍 了 React。 一 是 作为 View 库 , 它 怎 么 实现 组 件 化 ， 以 及 它 背 后 的 实现 原 
理 。 二 是 扩展 到 Flux 应 用 架构 及 重要 的 衍生 品 Redux， 它 们 怎么 与 React 结合 做 应 用 开发 。 三 是 
对 它 与 server 的 碰撞 产生 的 一 些 思考 。 四 是 讲述 它 在 可 视 化 方面 有 着 怎样 的 优势 与 劣势 。 
下 面 是 各 章 的 详细 介绍 。 
第 1 章 这 一 章 从 React 最 基本 的 概念 与 API 讲 起 ， 让 读者 熟悉 React 的 编码 过 程 。 
第 2 章 这 一 章 更 深入 到 React 的 方方面面 ， 并 从 一 个 具体 实例 的 实现 到 自动 化 测试 过 程 来 
述 React 组 件 化 的 过 程 和 思路 。 
第 3 章 这 一 章 深入 到 React 源码 ， 介 绍 了 React 背后 的 实现 原理 ,包括 Virtual DOM 、di 任 
算法 到 生命 周期 的 管理 ， 以 及 setstate 机 制 。 
第 4 章 这 一 章 介绍 了 React 官方 应 用 架构 组 合 Flux， 从 讲解 Flux 的 基本 概念 及 其 与 MV* 
架构 的 不 同 开始 ， 解 读 Flux 的 核心 思想 。 
第 5 章 这 一 章 介绍 了 业界 炙手可热 的 应 用 架构 Redux， 从 构建 一 个 SPA 应 用 讲 到 背后 的 
实现 逻辑 ， 并 扩展 了 Redux 生态 圈 中 常用 的 middleware 和 utils 方法 。 
第 6 章 这 一 章 讲述 Redux 高 阶 运用 ， 包 括 高 阶 reducer、 它 在 表单 中 的 运用 以 及 性 能 优化 
的 方法 。 另 外 ， 从 源码 的 角度 解读 了 Redux。 
第 7 章 这 一 章 介 绍 了 React 在 服务 端 演 染 的 方法 ， 并 从 一 个 实例 出 发 结合 Koa 完整 地 讲 
述 了 同 构 的 实现 。 
第 8 章 这 一 章 探 索 了 实现 可 视 化 图 形 图 表 的 方法 ， 以 及 如 何 通 过 这 些 方法 和 React 结合 在 
一 起 运转 。 
附录 A 探讨 了 React 开发 环境 的 基本 组 成 部 分 以 及 常规 的 安装 方法 。 
附录 B 探讨 了 团队 实践 或 多 人 协作 过 程 中 需要 关注 的 编码 规范 问题 。 
附录 C 探讨 了 Koa middleware 的 相关 知识 ， 帮 助理 解 Redux middleware。 
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代码 规范 

本 书 的 JavaScript 示例 代码 均 使 用 ES2015/ES6 编写 ， 并 遵循 Airbnb JavaScript 规范 ,但 诸如 
React 或 Redux 源 代码 引用 的 原始 代码 除外 。 

本 书 的 CSS 示例 代码 均 为 SCSS 代码 ， 但 引用 源码 库 的 CSS 除外 。 


























保留 英文 名 词 
对 于 React/Flux/Redux 中 常用 的 专 有 名 词 ， 在 不 造成 读者 理解 困难 的 情况 下 ， 本 书 尽量 保留 
英文 名 词 ， 保 持原 汁 原味 。 
口 Virtual DOM: 虚拟 DOM 
口 state: 状态 
口 props: 属性 
口 action: 动作 


口 reducer 








口 store 

口 middleware: 中 间 件 

口 dispatcher: 分 发 需 

D action creator: action 构造 需 


D currying: 柯 里 化 





读者 反馈 
如 果 你 有 什么 好 的 意见 和 建议 , 请 及 时 反馈 给 我 们 。 可 以 通过 iarcthur@gmailcom 或 在 知 乎 
上 发 私信 找到 我 。 

















示例 代码 下 载 

本 书 的 示例 代码 "托管 在 https://github.com/arcthur/react-book-examples 和 https://coding.net/u/ 
arcthur/p/react-book-examples/git， 它 可 能 会 和 书 中 的 内 容 有 所 出 入 ， 因 为 我 们 会 根据 情况 对 代码 
略 加 修改 ， 所 以 在 阅读 的 时 候 ， 建 议 结合 文档 一 同 查 看 。 





Qa 本 书 的 源 代码 也 可 从 图 灵 社 区 ( www.ituring.com.cn ) 本 书 主 页 免费 注册 下 载 。 











致谢 


从 React 诞生 以 来 ,我 就 在 关注 这 个 领域 。 在 2015 年 年 底 , 我 在 知 乎 上 开辟 了 名 为 purerender 
的 专栏 。 不 论 是 我 现在 的 角色 ， 还 是 从 建设 一 个 团队 的 角度 来 考虑 ， 我 都 想 把 在 React 实践 中 的 
心路 历程 分 享 出 来 ， 和 大 家 一 起 学 习 ， 共 同 成 长 。 

万 万 没 想 到 ， 专 栏 的 持续 写作 得 到 了 相当 多 知 友 的 认可 。 截 止 今天 ， 专 栏 运 行 8 个 月 左右 ， 
积累 了 20 篇 文章 ,得 到 了 4500 多 人 的 关注 。 对 于 团队 来 说 ， 既 是 鼓舞 ， 更 是 压力 。 专 栏 在 运行 
过 程 中 ， 参 与 的 伙伴 也 渐渐 变 多 ， 我 希望 它 可 以 一 直 保 持 高 质量 ， 让 整个 社区 的 React 爱好 者 们 
一 起 贡献 。 

专栏 写作 不 久 ， 就 有 几 位 编辑 老师 找到 我 ， 那 时 我 并 没有 准备 好 去 系统 地 撰写 一 些 内 容 , 但 
随 着 专栏 中 沉淀 的 文字 越 来 越 多 ， 我 想 不 妨 可 以 试 着 写 一 些 关 于 React 的 更 深入 的 分 析 ， 以 及 整 
体 应 用 层面 上 的 实践 ， 让 更 多 开发 者 ， 力 至 IT 圈 更 多 地 关注 这 个 库 。 在 写作 本 书 这 半年 多 的 时 
间 内 ，React 在 业界 的 关注 度 不 断 上 升 ， 也 涌现 出 很 多 优秀 的 实践 ， 我 非常 感谢 我 身 在 的 这 个 社 
区 全 

耗费 了 大 量 晚上 及 周末 的 时 间 ,， 断断续续 的 编写 与 修改 ， 书 稿 的 内 容 终于 定 下 来 了 ， 其 中 很 
多 内 容 是 对 专栏 已 有 内 容 的 修复 与 升级 。 书 与 专栏 同样 是 文字 的 传播 , 平台 不 同 , 初衷 却 是 一 样 
的 。 我 希望 它 可 以 精益 求 精 ， 至 少 能 在 一 定 程 度 上 帮助 开发 者 深入 学 习 React。 

在 此 ， 特 别 感 谢 知 乎 pure render 专栏 组 的 所 有 成 员 献 计 献 力 ， 其 中 杨森 、 丁 玲 、 李 梢 彬 、 黄 
宗 权 、 范 洪 春 、 宋 邵 英 、 胡 可 本 、 明 清亮 等 组 员 不 同 程度 地 贡献 了 实战 经 验 与 想法 ， 并 参与 审 校 
本 书 当 中 。 真 心 感谢 你 们 ， 是 你 们 的 热情 和 坚持 让 这 本 书 可 以 面世 。 

同样 感谢 写作 中 给 予 很 多 宝贵 意见 的 朋友 们 , 包括 魏 畅 然 、 赵 剑 飞 、 李 成 如、 胡 杰 、 郭 达 峰 、 
阮 一 峰 、 张 克 军 、 寸 志 、 张 克 炎 等 。 

最 后 ， 由 囊 地 感谢 王 军 花 老师 从 头 到 尾 认 真 负责 的 态度 ， 让 这 本 书 更 精彩 。 

































































































































































陈 屹 
2016 年 7 月 1 日 于 杭州 
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初 入 React 世界 











欢迎 进入 React 世界 。 从 本 章 开始 ， 不 论 你 是 刚刚 入门 的 前 端 开 发 者 ， 还 是 经 验 老道 的 资深 
工程 师 ， 都 可 以 学 习 到 React 的 基本 思想 以 及 基本 用 法 。 在 之 后 慢 慢 深入 的 过 程 中 ， 各 节 均 会 不 
同 程度 地 带 上 进 阶 的 实践 与 分 析 。 希 望 在 本 章 结束 时 ， 我 们 能 够 带领 你 实现 应 用 React 进行 基本 
的 组 件 开发 。 请 从 这 里 开始 你 的 旅程 …… 





1.1 React 简介 


React 是 Facebook 在 2013 年 开源 在 GitHub 上 的 JavaScript 库 。React 把 用 户 界 面 抽象 成 一 个 
个 组 件 ， 如 按钮 组 件 Button 、 对 话 框 组 件 Dialog、 日 期 组 件 Calendar。 开 发 者 通过 组 合 这 些 组件 ， 
最 终 得 到 功能 丰富 、 可 交互 的 页 面 。 通 过 引入 JSX 语 法 , 复 用 组 件 变 得 非常 容易 ， 同 时 也 能 保证 
组 件 结构 清晰 。 有 了 组 件 这 层 抽象 ，React 把 代码 和 真实 泻 染 目标 隔离 开 来 ， 除 了 可 以 在 浏览 
端 泻 染 到 DOM 来 开发 网 页 外 ， 还 能 用 于 开发 原生 移动 应 用 。 











1.1.1 专注 视图 层 


现在 的 应 用 已 经 变 得 前 所 未 有 的 复杂 ， 因 而 开发 工具 也 必须 变 得 越 来 越 强 大 。 和 Angular、 
Ember 等 框架 不 同 ，React 并 不 是 完整 的 MVC/MVVM 框架 ， 它 专注 于 提供 清晰 、 简 洁 的 View 
(视图 ) 层 解决 方案 。 而 又 与 模板 引擎 不 同 ，React 不 仅 专 注 于 解决 View 层 的 问题 ， 又 是 一 个 包 
括 View 和 Controller 的 库 。 对 于 复杂 的 应 用 ， 可 以 根据 应 用 场景 自行 选择 业务 层 框 架 ， 并 根据 
需要 搭配 Flux、Redux 、GraphQL/Relay 来 使 用 。 

React 不 像 其 他 框架 那样 提供 了 许多 复杂 的 概念 与 烦琐 的 API， 它 以 Minimal API Interface 为 
目标 ， 只 提供 组 件 化 相关 的 非常 少量 的 API。 同 时 为 了 保持 灵活 性 ， 它 没有 自 创 一 套 规则 ， 而 是 
尽 可 能 地 让 用 户 使 用 原生 JavaScript 进行 开发 。 只 要 熟悉 原生 JavaScript 并 了 解 重要 概念 后 ， 就 
可 以 很 容易 上 手 React 应 用 开发 。 









































1.1.2 Virtual DOM 
真实 页 面 对 应 一 个 DOM 树 。 在 传统 页 面 的 开发 模式 中 ， 每 次 需要 更 新 页 面 时 ， 都 要 手动 操 
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作 DOM 来 进行 更 新 ， 如 图 1-1 所 示 。 























事件 触发 

图 1-1 传统 DOM 更 新 

DOM 操作 非常 昂贵 。 我 们 都 知道 在 前 端 开 发 中 ， 人 性 能 消耗 最 大 的 就 是 DOM 操作 ， 而 且 这 

部 分 代码 会 让 整体 项 目的 代码 变 得 难以 维护 。React 把 真实 DOM 树 转 换 成 JavaScript 对 象 树 ， 也 
就 是 Virtual DOM， 如 图 1-2 所 示 。 

















改变 改变 








事件 触发 事件 触发 
图 1-2 ”ReactDOM 更 新 


每 次 数据 更 新 后 ， 重 新 计算 Virtual DOM， 并 和 上 一 次 生成 的 Virtual DOM 做 对 比 ， 对 发 生 
变化 的 部 分 做 批量 更 新 。React 也 提供 了 直观 的 shouLdComponentUpdate 生命 周期 回调 ,来 减少 数 
据 变 化 后 不 必要 的 Virtual DOM 对 比 过 程 ， 以 保证 性 能 。 

我 们 说 Virtual DOM 提升 了 React 的 性 能 , 但 这 并 不 是 React 的 唯一 亮点 。 此 外 , Virtual DOM 
的 演 染 方式 也 比 传统 DOM 操作 好 一 些 , 但 并 不 明显 , 因为 对 比 DOM 节点 也 是 需要 计算 资源 的 。 

它 最 大 的 好 处 其 实 还 在 于 方便 和 其 他 平台 集成 ,比如 react-native 是 基于 Virtual DOM 演 染 出 
原生 控件 ， 因 为 React 组 件 可 以 映射 为 对 应 的 原生 控件 。 在 输出 的 时 候 ， 是 输出 Web DOM， 还 
是 Android 控件 ,还 是 iOS 控件 ,就 由 平台 本 身 决定 了 。 因 此 ，react-native 有 一 个 口号 一 一 Learn 
Once, Write Anywhere。 








































































































1.1.3 ”函数 式 编程 


在 过 去 , 工业 界 的 编程 方式 一 直 以 命令 式 编程 为 主 。 命令 式 编程 解决 的 是 做 什么 的 问题 ， 比 
如 图 灵机 , 而 现代 计算 机 就 是 一 个 经 历 了 多 次 进化 的 高 级 图 灵机 。 如 果 说 人 脑 最 擅长 的 是 分 析 问 
题 , 那么 电脑 最 擅长 的 就 是 执行 指令 , 电脑 只 需要 几 条 汇编 指令 就 可 以 轻松 算出 我 们 需要 很 长 时 





























1.2 JSX 语法 3 





















































间 才 能 解 出 的 运算 。 命 令 式 编程 就 像 是 在 给 电脑 下 命令 , 现在 主要 的 编程 语言 (包括 C 和 Java 等 ) fk 
都 是 由 命令 式 编程 构建 起 来 的 。 

而 函数 式 编程 ， 对 应 的 是 声明 式 编程 ， 它 是 人 类 模仿 自己 逻辑 思考 方式 发 明 出 来 的 。 声 明 式 
编程 的 本 质 是 lambda 演算 ?。 试想 当 我 们 操作 数组 的 每 个 元 素 并 返回 一 个 新 数组 时 ， 如 果 是 计算 
机 的 思考 方式 ， 则 是 需要 一 个 新 数组 ,然后 遍历 原 数组 ， 并 计算 赋值 ; 如 果 是 人 的 思考 方式 ， 则 
是 构建 一 个 规则 ， 这 个 过 程 就 变 成 构建 一 个 f 函数 作用 在 数组 上 ， 然 后 返回 新 数组 。 这样， 计算 
可 以 被 重复 利用 。 

当 回 到 UI 界面 上 ， 我 们 的 产品 经 理 又 想 出 了 一 个 新 点 子 时 ， 我 们 是 抱怨 呢 ， 还 是 去 思考 怎 
么 解决 这 个 问题 。React 把 过 去 不 断 重复 构建 UI 的 过 程 抽象 成 了 组 件 , 且 在 给 定 参 数 的 情况 下 约 
定 泻 染 对 应 的 UI 界面 。React 能 充分 利用 很 多 函数 式 方法 去 减少 元 余 代 码 。 此外， 由 于 它 本 身 就 
是 简单 函数 ， 所 以 易于 测试 。 可 以 说 ,函数 式 编程 才 是 React 的 精髓。 












































































































































1.2 JSX 语法 


当初 学 React 时 ，JSX 是 我 们 遇 到 的 第 一 个 新 概念 。 也 许 我 们 都 是 写 惯 了 JavaScript 程序 的 
开发 者 ， 对 于 类 似 于 静态 编译 并 不 感冒 。 早 些 年 风靡 前 端 界 的 CoffeeScript， 也 因为 ES6 标准 化 
的 加 速 推进 ， 慢 慢 变 为 了 茶余饭后 的 谈资 。 面 对 React， 我 们 又 一 次 需要 玩 转 一 门 新 的 静态 转译 
语言 ， 而 这 一 次 ， 又 会 有 什么 不 一 样 的 体验 呢 。 




















1.2.1 JSX 的 由 来 


JSX 与 React 有 什么 关系 呢 ? 简单 来 讲 ，React 为 方便 View 层 组 件 化 ， 承 载 了 构建 HTML 结 
构 化 页 面 的 职责 。 从 这 点 上 来 看 ，React 与 其 他 JavaScript 模板 语言 有 着 许多 异曲同工 之 处 , 但 
不 同 之 处 在 于 React 是 通过 创建 与 更 新 虚拟 元 素 ( virtual element ) 来 管理 整个 Virtual DOM 的 。 








说 明 JSX 语 言 的 名 字 最 早出 现在 游戏 厂商 DeNA， 但 和 React 中 的 JSX 不 同 的 是 ， 它 意 在 通过 
加 入 增强 语法 ， 使 得 JavaScript 变 得 更 快 、 更 安全 、 更 简单 。 




















其 中 ,虚拟 元 素 可 以 理解 为 真实 元 素 的 对 应 , 它 的 构建 与 更 新 都 是 在 内 存 中 完成 的 ， 并 不 会 
真正 泻 染 到 DOM 中 去 。 在 React 中 创建 的 虚拟 元 素 可 以 分 为 两 类 ，DOM 元 素 (DOM element ) 
与 组 件 元素 ( component element )， 分 别 对 应 着 原生 DOM 元 素 与 自 定 义 元 素 ， 而 JSX 与 创建 元 
素 的 过 程 有 着 莫大 的 关联 。 

接着 ， 我 们 从 这 两 种 元 素 的 构建 开始 说 起 。 











GD lambda calculus， 详 见 https:Wen.wikipedia.org/wiki/Lambda_calculus。 
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1. DOM 元 素 

















从 过 往 的 经 验 中 知道 ，Web 页 面 是 由 一 个 个 HTML 元 素 般 套 组 合 而 成 的 。 当 使 用 JavaScript 
来 描述 这 些 元 素 的 时 候 ， 这 些 元 素 可 以 简单 地 被 表示 成 纯粹 的 JSON 对 象 。 比 如 ， 现 在 需要 描述 
一 个 按钮 (button )， 这 用 HTML 语法 表示 非常 简单 : 

















<button class="btn btn-blue"> 
<em>Confirm</em> 
</button> 





其 中 包括 了 元 素 的 类 型 和 属性 。 如 果 转 成 JSON 对 象 ， 那 么 依然 包括 元 素 的 类 型 以 及 属性 : 


{ 
type: 'button', 
props: { 
className: 'btn btn-blue', 
children: [{ 
type: 'em', 
props: { 
children: "Confirm' 





}] 


这 样 ， 我 们 就 可 以 在 JavaScript 中 创建 Virtual DOM 元 素 了 。 























在 React 中 ， 到 处 都 是 可 以 复 用 的 元 素 ， 这 些 元 素 并 不 是 真实 的 实例 ， 它 只 是 让 React 告诉 
开发 者 想 要 在 屏幕 上 显示 什么 。 我 们 无 法 通过 方法 去 调用 这 些 元 素 , 它们 只 是 不 可 变 的 描述 对 象 。 

2. 组 件 元 素 

当然 ， 我 们 可 以 很 方便 地 封装 上 述 button 元 素 ， 得 到 一 种 构建 按钮 的 公共 方法 : 


人 六 











const Button = ({ color, text }) => { 
return { 
type: 'button', 
props: { 
className: ‘btn btn-SfcoLor} ， 
children: { 
type: 'em', 
props: { 
children: text, 


}, 


自然 ， 当 我 们 要 生成 DOM 元 素 中 具体 的 按钮 时 ， 就 可 以 方便 地 调用 Button({color:'blue'， 
text:'Confirm'}) 来 创建 。 
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仔细 思考 这 个 过 程 可 以 发 现 ，Button 方法 其 实 也 可 以 作为 元 素 而 存在 ,方法 名 对 应 了 DOM ol 
元 素 类 型 ， 参 数 对 应 了 DOM 元 素 属性 ， 那 么 它 就 具备 了 元 素 的 两 大 必要 条 件 ， 这 样 构 建 的 元 素 
就 是 自 定义 类 型 的 元 素 ,或 称 为 组 件 元 素 。 我 们 用 JSON 结构 来 描述 它 : 


{ 
type: Button, 
props: { 
color: 'blue', 
children: 'Confirm' 


} 
} 


这 也 是 React 的 核心 思想 之 一 。 因 为 有 公共 的 表达 方法 ,我 们 就 可 以 让 元 素 们 彼此 髓 套 或 混 
合 。 这 些 层 层 封装 的 组 件 元 素 ， 就 是 所 谓 的 React 组 件 ， 最 终 我 们 可 以 用 递归 演 染 的 方式 构建 出 
完全 的 DOM 元 素 树 。 

我 们 再 来 看 一 个 封装 得 更 深 的 例子 。 为 上 述 Button 元 素 再 封装 一 次 , 它 由 一 个 方法 构建 而 成 : 










































































const DangerButton = ({ text }) => ({ 
type: Button, 
props: { 
color: 'red', 
children: text 
} 
]); 


直观 地 看 ，DangerButton 从 视觉 上 为 我 们 定义 了 “和 危险 的 按钮 ”这 样 一 种 新 的 组 件 元 素 。 接 
着 ,我 们 可 以 很 轻松 地 运用 它 ， 继 续 封 装 新 的 组 件 元 素 : 


const DeleteAccount = () => ({ 
type: 'div', 
props: { 
children: [{ 
type: 'p', 
props: { 
children: 'Are you sure?', 
}, 
十 
type: DangerButton ， 
props: { 
children: 'Confirm', 
}, 
}, { 
type: Button, 
props: { 
color: 'blue', 
children: 'Cancel', 
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DeleteAccount 清晰 地 表达 了 一 个 功能 模块 、 一 段 提 示 语 、 一 个 表示 确认 的 警示 按钮 和 一 个 
表示 取消 的 普通 按钮 。 不 过 在 表达 还 不 怎么 复杂 的 结构 时 ， 它 就 力不从心 了 。 这 让 我 们 想起 使 用 
HTML 书写 结构 时 的 畅快 感受 , JSX 语 法 为 此 应 运 而 生 。 假如 我 们 使 用 JSX 语法 来 重新 表达 上 述 
组 件 元 素 ， 只 需 这 么 写 : 


























const DeleteAccount = () => ( 
<div> 
<p>Are you sure?</p> 
<DangerButton>Confirm</DangerButton> 
<Button color="blue">Cancel</Button> 
</div> 


); 


注意 上 述 DeleteAccount 并 不 是 真实 转换 ， 在 实际 场景 中 构建 元 素 会 考虑 到 诸如 安全 等 因素 ， 
会 由 React 内 部 方法 创建 虚拟 元 素 。 如 果 需 要 自己 构建 虚拟 元 素 ， 原 理 也 是 一 样 的 。 


如 你 所 见 ，JSX 将 HTML 语法 直接 加 入 到 JavaScript 代码 中 ， 再 通过 翻译 器 转换 到 纯 
JavaScript 后 由 浏览 器 执行 。 在 实际 开发 中 ，JSX 在 产品 打包 阶段 都 已 经 编译 成 纯 JavaScript， 不 
会 带 来 任何 副作用 ,反而 会 让 代码 更 加 直观 并 易于 维护 。 尽管 JSX 是 第 三 方 标 准 , 但 这 套 标准 适 
用 于 任何 一 套 框架 。 

React 官方 在 早期 为 JSX 语法 解析 开发 了 一 套 编译 髓 JSTransform, 目前 已 经 不 再 维护 ,现在 
已 全 部 采用 Babel 的 JSX 编译 器 实现 。 因 为 两 者 在 功能 上 完全 重复 ， 而 Babel 作为 专门 的 
JavaScript 语法 编译 工具 ， 提 供 了 更 为 强大 的 功能 ， 达 到 了 “一 处 配置 ， 统 一 运行 ”的 目的 。 


我 们 试 着 将 DeleteAccount 组 件 通过 Babel 转译 成 React 可 以 执行 的 代码 : 






























































var DeleteAccount = function DeleteAccount() { 
return React.createElement( 

'div', 

null, 

React.createELement( 
'p', 
null, 
'Are you sure? 

i 

React.createELement( 
DangerButton ， 
null, 
"Confirm' 

bp 

React.createELement( 
Button, 
{ color: 'blue' }, 
'Cancel’ 

) 

); 
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}; 

可 以 看 到 ， 除 了 在 创建 元 素 时 使 用 React.createElement 创建 之 外 ， 其 结构 与 一 直 在 讲 的 
JSON 的 结构 是 一 致 的 。 

反 过 来 说 ，JSX 并 不 是 强制 选项 ,我 们 可 以 像 上 述 代 码 那 样 直接 书写 而 无 须 编译 ,但 这 实在 
是 极其 酸 糕 的 编程 体验 。JSX 的 出 现 为 我 们 省 去 了 这 个 烦琐 过 程 , 使 用 JSX 写法 的 代码 更 易于 阅 
读 与 开发 。 事 实 上 ，JSX 并 不 需要 花 精 力学 习 。 只 要 你 熟悉 HTML 标签 ， 大 多 数 功能 就 都 可 以 
直接 使 用 了 。 



















































































1.2.2 ”JSX 基本 语法 


JSX 的 官方 定义 是 类 XML 语法 的 ECMAScript 扩展 。 它 完美 地 利用 了 JavaScript 自 带 的 语法 
和 特性 ， 并 使 用 大 家 熟悉 的 HTML 语法 来 创建 虚拟 元 素 。 可 以 说 ，JSX 基本 语法 基本 被 XML 者 
括 了 ， 但 也 有 少许 不 同 之 处 。 接 着 我 们 从 基本 语法 、 元 素 类 型 、 元 素 属 性 、JavaScript 属性 表达 
式 等 维度 一 一 讲述 。 

1. XML 基本 语法 


使 用 类 XML 语法 的 好 处 是 标签 可 以 任意 向 套 ， 我们 可 以 像 HTML 一 样 清晰 地 看 到 DOM 树 
状 结构 及 其 属性 。 比 如 ， 我 们 构造 一 个 List 组 件 : 
Const List = () => ( 
<div> 
<Title>This is title</Title> 
<ul> 
<li>list item</li> 
<li>list item</li> 
<li>list item</li> 
</ul> 
</div> 
); 
写 List 的 过 程 就 像 写 HTML 一 样 , 只 不 过 它 被 包 庄 在 JavaScript 的 方法 中 , 需要 注意 以 下 几 点 。 
口 定义 标签 时 ， 只 允许 被 一 个 标签 包 庄 。 例 如 ，const component = <span>name</span><span> 
value</span> 这 样 写 会 报错 。 原 因 是 一 个 标签 会 被 转译 成 对 应 的 React.createELement 调 
用 方法 ， 最 外 层 没有 被 包 庄 ， 显 然 无 法 转译 成 方法 调用 。 
口 标签 一 定 要 闭合 。 所 有 标签 ( 比如 <div></div>、<p></p> ) 都 必须 闭合 ， 否 则 无 法 编译 通 
过 。 其 中 HTML 中 自 闭合 的 标签 (如 <img> ) 在 JSX 中 也 遵循 同样 规则 ， 自 定义 标签 可 
以 根据 是 否 有 子 组 件 或 文本 来 决定 闭合 方式 。 
当然 ，JSX 报错 机 制 非 党 强大， 如 果 有 拼写 错误 时 ， 可 以 直接 在 控制 台 打 印 出 来 。 
2. 元 素 类 型 


在 1.2 节 中 ,我们 讲 到 两 种 不 同 的 元 素 : DOM 元 素 和 组 件 元 素 。 在 JSX 里 自然 会 有 对 应 ， 
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对 应 规则 是 HTML 标签 首 字母 是 否 为 小 写字 母 ， 其 中 小 写 首 字母 对 应 DOM 元 素 ， 而 组 件 元 素 自 
然 对 应 大 写 首 字母 。 
比如 List 组 件 中 的 <div> 标签 会 生成 DOM 元 素 ，Titte 以 大 写字 母 开 头 ， 会 生成 组 件 元 素 : 


const Title = (children) => ( 
<h3>{children}</h3> 
9 


等 到 依赖 的 组 件 元 素 中 不 再 出 现 组 件 元 素 ， 我 们 就 可 以 将 完整 的 DOM 树 构 建 出 来 了 。 
JSX 还 可 以 通过 命名 空间 的 方式 使 用 组 件 元 素 ， 以 解决 组 件 相同 名 称 冲 突 的 问题 ， 或 是 对 一 
组 组 件 进行 归 类 。 比 如 ， 我 们 想 使 用 Material UI 组 件 库 中 的 组 件 ， 以 MUI 为 包 名 ， 可 以 这 么 写 : 





const App = () => ( 
<MUI.RaisedButton label="Default" /> 
) 


在 HTML 标准 中 ， 还 有 一 些 特殊 的 标签 值得 讨论 ， 比 如 注释 和 DOCTYPE 头 。 

@ 注释 

在 HIML 中 ,注释 写成 <!-- content --> 这 样 的 形式 ， 但 在 JSX 中 并 没有 定义 注释 的 转换 
方法 。 事 实 上 ，JSX 还 是 JavaScript， 依 然 可 以 用 简单 的 方法 使 用 注释 ， 唯 一 要 注意 的 是 ， 在 
个 组 件 的 子 元 素 位 置 使 用 注释 要 用 {} 包 起 来 。 示 例 代码 如 下 : 


const App = ( 
<Nav> 
{/* 节点 注释 */} 
<Person 
/* 多 行 
注释 */ 
name={window.isLoggedIn ? window.name : ''} 
/> 
</Nav> 


); 
但 HTML 中 有 一 类 特殊 的 注释 一 一 条 件 注释 ， 它 常用 于 判断 浏览 器 的 版 本 : 



































<!--[if IE]> 
<p>Work in IE browser</p> 
<![endif]--> 


上 述 方法 可 以 通过 使 用 JavaScript 判断 浏览 器 版 本 来 蔡 代 : 





{ 


(!!window.ActiveXObject || 'ActiveXObject' in window) ? 
<p>Work in IE browser</p> : 


} 
一 般 来 说 ， 条 件 注释 的 使 用 场景 是 在 <head> 中 判断 加 载 对 应 的 脚本 或 样式 。 在 服务 端 演 染 
中 ， 我 们 还 会 遇 到 这 样 的 场景 ， 在 0.14 版 本 中 可 以 使 用 <meta> 标签 来 实现 : 
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<meta dangerousLySetInnerHTML={ 
_html: “ 
<!--[if IE]> 
<script src="//example.org/app.js"></script> 
<![endif]--> 


} /> 
但 在 15.0 版 本 中 这 已 经 不 可 用 。 因 此 ， 还 是 建议 在 JavaScript 里 判断 浏览 器 版 本 ， 进 行 一 些 
特有 的 操作 。 
@ DOCTYPE 
DOCTYPE 头 是 一 个 非常 特殊 的 标志 ， 一 般 会 在 使 用 React 作为 服务 端 泻 染 时 用 到 。 在 HTML 
中 ，DocTYPE 是 没有 闭合 的 ， 也 就 是 说 我 们 无 法 泻 染 它 。 
常见 的 做 法 是 构造 一 个 保存 HTML 的 变量 ， 将 DOCTYPE 与 整个 HTML 标签 泻 染 后 的 结果 虽 
连 起 来 。 第 7 章 会 详细 讲 到 。 
3. 元 素 属 性 
元 素 除 了 标签 之 外 ， 另 一 个 组 成 部 分 就 是 标签 的 属性 。 
在 JSX 中 ,不 论 是 DOM 元 素 还 是 组 件 元 素 ， 它 们 都 有 属性 。 不 同 的 是 ，DOM 元 素 的 属性 
是 标准 规范 属性 ,但 有 两 个 例外 class 和 for， 这 是 因为 在 JavaScript 中 这 两 个 单词 都 是 关键 
词 。 因 此 ， 我 们 这 么 转换 : 
口 class 属性 改 为 className; 
口 for 属性 改 为 htmLFor。 
而 组 件 元 素 的 属性 是 完全 自 定义 的 属性 ， 也 可 以 理解 为 实现 组 件 所 需要 的 参数 。 比 如 : 
const Header = ({title, children}) => ( 
<h3 title={title}>{children}</h3> 
); 
我 们 给 Header 组 件 加 了 一 个 tittle 属性 ， 那 么 可 以 这 么 调用 : 
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<Header title="hello world">Hello world</Header> 


当然 , 我 们 可 以 再 给 Header 组 件 加 上 color 等 属性 。 可 以 看 到 , Header 和 h3 中 两 个 title 的 
不 同 之 处 , 一 个 代表 的 是 自 定义 标签 的 属性 可 以 传递 , 一 个 是 标签 自 带 的 属性 无 法 传递 。 值 得 注 
意 的 是 ， 在 写 自 定义 属性 的 时 候 ， 都 由 标准 写法 改 为 小 驼峰 写法 。 

此 外 ， 还 有 一 些 JSX 特有 的 属性 表达 。 

@ Boolean 属性 


省 略 Boolean 属性 值 会 导致 JSX 认为 bool 值 设 为 了 true。 要 传 false 时 ， 必 须 使 用 属性 表 
达 式 。 这 常用 于 表单 元 素 中 ， 比 如 disabled、required、checked 和 readontLy 等 。 
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例如 ，<Checkbox checked={true} /> 可 以 简写 为 <Checkbox checked />， 反 之 <Checkbox 
checked={false} /> 就 可 以 省 略 checked 属性 。 


@ 展开 属性 
如 果 事 先知 道 组 件 需 要 的 全 部 属性 ，JSX 可 以 这 样 来 写 : 














const component = <Component name={name} value={value} />; 


如 果 你 不 知道 要 设置 哪些 props， 那 么 现在 最 好 不 要 设置 它 : 





const component = <Component />; 
component.props.name = name; 
Component .props.VvaLue = value; 


上 述 这 样 是 反 模式 ， 因 为 React 不 能 帮 你 检查 
类 型 有 错误 ， 也 不 能 得 到 清晰 的 错误 提示 。 
这 里 ， 可 以 使 用 ES6 rest/spread 特性 来 提高 效率 : 


const data = { name: 'foo', value: 'bar' }; 
const component = <Component name={data.name} value={data.value} />; 


可 以 写成 : 

















| 


性 类 型 (propTypes )。 这 样 即 使 组 件 的 属性 








const data = { name: 'foo', value: 'bar' }; 
const component = <Component {...data} />; 


@ 自 定 义 HTML 属性 

如 果 在 JSX 中 往 DOM 元 素 中 传人 自 定义 属性 ，React 是 不 会 泻 染 的 : 

<div d="xxx">content</div> 

如 果 要 使 用 HTML 自 定义 属性 ， 要 使 用 data- 前 级 ， 这 与 HTML 标准 也 是 一 致 的 : 

<div data-attr="xxx">content</div> 

然而 ， 在 自 定义 标签 中 任意 的 属性 都 是 被 支持 的 : 

<x-my-component custom-attr="foo" /> 

以 aria- 开头 的 网 络 无 障碍 属性 同样 可 以 正常 使 用 : 

<div aria-hidden={true}></div> 

不 论 组 件 是 用 什么 方法 来 写 , 我 们 都 需要 知道 , 组 件 的 最 终 目的 是 输出 虚拟 元 素 , 也 就 是 需 
要 被 泻 染 到 界面 的 结构 。 其 核心 泻 染 方法 ,或 称 为 组 件 输出 方法 ， 就 是 render 方法 。 它 是 React 
组 件 生命 周期 的 一 部 分 ， 也 是 最 核心 的 函数 之 一 。1.5 节 将 详细 解释 整个 生命 周期 的 运作 。 

4. JavaScript 属性 表达 式 
属性 值 要 使 用 表达 式 ， 只 要 用 {} 替换 "" 即 可 : 
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// 输入 (JSX) : 


const person = <Person name={window.isLoggedIn ? window.name : ''} />; 


// 输出 (JavaScript) : 
Const person = React.createELement( 
Person, 
{name: window.isLoggedIn ? window.name : ''} 


); 
子 组 件 也 可 以 作为 表达 式 使 用 : 


// 输入 (JSX) : 


const content = <Container>{window.isLoggedIn ? <Nav /> : <Login />}</Container>; 


// 输出 (JavaScript) : 
const content = React.createElement( 
Container, 
null, 
window.isLoggedIn ? React.createElement(Nav) : React.createElement(Login) 


); 
5. HTML 转 义 
React 会 将 所 有 要 显示 到 DOM 的 字符 串 转 义 ， 防 止 XSS。 所 以 ， 如 果 JSX 中 含有 转 义 后 的 


实体 字符 ， 比 如 &copy; (@ )， 则 最 后 DOM 中 不 会 正确 显示 ， 因 为 React 自动 把 &copy; 中 的 特 
殊 字 符 转 义 了 。 有 几 种 解决 办 法 : 


口 直接 使 用 UTF-8 字符 ©; 
口 使 用 对 应 字符 的 Unicode 编码 查询 编码 ; 
口 使 用 数组 组 装 <div>{['cc '，<span>&copy;</span>，' 2015']}</div>; 
口 直接 插入 原始 的 HIML。 
此 外 ，React 提供 了 dangerousLySetInnerHTML 属性 。 正 如 其 名 ， 它 的 作用 就 是 避免 React 转 
义 字 符 ， 在 确定 必要 的 情况 下 可 以 使 用 它 : 


<div dangerouslySetInnerHTML={{__html: "cc &copy; 2015'}} /> 


















































1.3” React 组 件 


终于 说 到 我 们 最 为 关心 的 React 组 件 了 。 在 React 诞生 之 前 ， 前 端 界 对 于 组 件 的 封装 实现 一 
直 都 处 在 摸索 和 实践 的 阶段 。 








1.3.1 组 件 的 演变 
在 MV* 架构 出 现 之 前 ， 组 件 主要 分 为 两 种 。 
口 狭义 上 的 组 件 ， 又 称 为 UI 组件 ， 比 如 Tabs 组 件 、Dropdown 组 件 。 组 件 主要 围绕 在 交互 





12 第 1 章 ， 初 入 React 世界 











动作 上 的 抽象 ， 针 对 这 些 交 互动 作 ， 利 用 JavaScript 操作 DOM 结构 或 style 样式 来 控制 。 
口 广义 上 的 组 件 ， 即 带 有 业务 含义 和 数据 的 UI 组 件 组 合 。 这 类 组 件 不 仅 有 交互 动作 ， 更 重 
要 的 是 有 数据 与 界面 之 间 的 交互 。 然 而 ， 这 类 组 件 往往 有 较 大 的 争议 。 在 规模 较 大 的 场 
景 下 ， 我 们 更 倾向 于 采用 分 层 的 思想 去 处 理 。 
以 常用 的 Tabs 组 件 为 例 ， 对 于 UI 组 件 来 说 ， 一 定 会 有 3 个 部 分 组 件 : 结构 、 样 式 和 交互 行 
为 ， 分 别 对 应 着 HIML 、CSS 和 JavaScript。 一 般 情况 下 ， 我 们 会 先 构 建 组 件 的 基本 结构 : 



































<div id="tab-demo"> 
<div class="tabs-bar" role="tablist"> 
<ul class="tabs-nav"> 
<li role="tab" class="tabs-tab">Tab 1</\li> 
<li role="tab" class="tabs-tab">Tab 2</\li> 
<li role="tab" class="tabs-tab">Tab 3</\li> 
</ul> 
</div> 
<div class="tabs-content"> 
<div role="tabpanel" class="tabs-panel"> 
第 一 个 Tab 里 的 内 容 
</div> 
<div role="tabpanel" class="tabs-panel"> 
第 二 个 Tab 里 的 内 容 
</div> 
<div role="tabpanel" class="tabs-panel"> 
第 三 个 Tab 里 的 内 容 
</div> 
</div> 
</div> 


这 个 结构 对 我 们 来 说 非常 熟悉 ， 其 中 tabs-bar 中 的 内 容 是 组 件 的 导航 区 域 ， 而 tabs- 
content 中 的 内 容 自然 就 是 组 件 的 内 容 区 域 。 利 用 JavaScript 和 CSS 来 控制 对 应 索引 的 导航 激活 ， 
且 显 示 内 容 区 域 。 


现在 ， 我 们 就 按照 图 1-3 来 定义 组 件 的 样式 。 


Tab1 Tab2 Tab3 














图 1-3 ”组件 样式 





样式 代码 如 下 : 
$class-prefix: "tabs"; 


.#{$class-prefix} { 
&-bar { 
margin-bottom: 16px; 


} 


&-nav { 
font-size: 14px; 
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&:after， 

&:before { 
display: table; 
content: "~ "; 


} 


&:after { 
clear: both; 


} 


-nav > &-tab { 

float: left; 
list-style: none; 
margin-right: 24px; 
padding: 8px 20px; 
text-decoration: none; 
color: #666; 

cursor: pointer; 


-Nav > &-active { 

border-bottom: 2px solid #00C49F; 
color: #00C49F; 

cursor: default; 


. 


&-content &-panel { 
display: none; 


} 


&-content &-active { 
display: block; 
} 


这 里 我 们 用 SCSS 来 定义 组 件 的 样式 ， 这 样 可 以 方便 地 定义 class 前 


组 件 主 题 的 目的 。 
最 后 是 交互 行为 。 我 们 引入 jQuery 方便 操作 DOM,， 使 月 























又 
缀 » 


以 达到 定义 一 系列 





月 ES6 classes 语法 糖 来 蔡 换 早期 利用 


原型 构建 面向 对 象 的 方法 ， 以 及 使 用 ES6 modules 替换 AMD 模块 加 载 机 制 : 


import $ from 'jquery'; 
import EventEmitter from 'events'; 


const Selector = (classPprefix) => ({ 
PREFIX: classPprefix, 
NAV: `${classPrefix}-nav., 
CONTENT: ‘S${classPprefix}-content., 
TAB: ‘S${classPrefix}-tab, 
PANEL: ‘S${classPrefix}-panel., 
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ACTIVE: ‘S${classPprefix}-active., 
DISABLE: ‘${classPprefix}-disable., 


}); 


class Tabs { 
static defaultOptions = { 
classPrefix: 'tabs', 
activeIndex: 0， 


}; 


constructor(options) { 
this.options = $.extend({}, Tabs.defaultOptions, options); 
this.element = $(this.options.element); 
this.fromIndex = this.options.activeIndex; 


this.events = new EventEmitter(); 
this.selector = Selector(this.options.classPrefix); 


this._ initElement(); 
this. initTabs(); 
this._initpanels(); 
this._bindTabs(); 


if (this.options.activeIndex !== undefined) { 
this.switchTo(this.options.activeIndex); 
} 
} 


_initElement() { 
this.element.addClass(this.selector .PREFIX); 
this.tabs = $(this.options.tabs); 
this.panels = $(this.options.panels); 
this.nav = $(this.options.nav); 
this.content = $(this.options.content); 


this. length = this.tabs. length; 
} 


_initTabs() { 
this.nav && this.nav.addClass(this.selector.NAV); 
this. tabs.addClass(this.selector .TAB).each((index, tab) => { 
s(tab).data('value', index); 
]); 
} 


_initpanels() { 
this.content.addClass(this.selector .CONTENT) ; 
this.paneLs.addCLass(this.seLector .PANEL ) ; 

} 


_bindTabs() { 
this.tabs.click((e) => { 
const $el = $(e.target); 
if (!S$el.hasClass(this.selector.DISABLE)) { 
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this.switchTo(S$el.data('valuye')); 


]); 
} 


events(name) { 
return this.events; 


} 


switchTo(toIndex) { 
this._switchTo(toIndex); 


了 


_switchTo(toIndex) { 
const fromIndex = this.fromIndex; 
const paneLInfo = this. getPanelInfo(toInNndex); 


this._switchTabs(toIndex); 
this._switchpanel(panelInfo); 
this.events.emit('change', { toIndex, fromIndex }); 


this.fromIndex = toIndex; 


l 


_switchTabs(toIndex) { 
const tabs = this.tabs; 
const fromIndex = this.fromIndex; 


if (tabs.length < 1) return; 


tabs 
.eq(fromIndex) 
.removeClass(this.selector .ACTIVE) 
.attr('aria-selected', false); 
tabs 
.eq(toIndex) 
.addClass(this.selector .ACTIVE) 
.attr('aria-selected', true); 


} 


_switchPpanel(panelInfo) { 
panelInfo.frompanels 
.attr('aria-hidden', true) 
.hide(); 
panelInfo.toPanels 
.attr('aria-hidden', false) 
.Show(); 
} 


_getPanelInfo(toIndex) { 
const panels = this.panels; 


const fromIndex = this.fromIndex; 


let frompanels, toPanels; 
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if (fromIndex > -1) { 
frompanels = this.panels.slice(fromIndex, (fromIndex + 1)); 


} 


topPanels = this.panels.slice(toIndex, (toIndex + 1)); 


return { 
toIndex: toIndex, 
fromIndex: fromIndex, 
toPaneLs: $(toPpanels), 
fromPaneLs: $(frompanels), 
}; 
} 


destroy() { 
this.events.removeAllListeners(); 


} 
} 


export defaults Tabs; 


初始 化 过 程 十 分 简洁 ， 实 例 化 组 件 并 传人 必要 的 几 个 参数 就 可 以 赋予 交互 : 





const tab = new Tabs({ 
element: '#tab-demo', 
tabs: '#tab-demo .tabs-nav li', 
panels: '#tab-demo .tabs-content div', 
activeIndex: 1， 


]); 


tab .events.on( 'change' ，(o) => { 
ConsotLe.Log(o); 


]); 

我 们 看 到 ， 组 件 封装 的 基本 思路 就 是 面向 对 象 思 想 。 交 互 基本 上 以 操作 DOM 为 主 ， 逻 辑 上 
是 结构 上 哪里 需要 变 ， 我们 就 操作 哪里 。 此 外 ， 对 于 JavaScript 的 结构 ， 我 们 得 到 了 几 项 规范 标 
准 组 件 的 信息 。 
口 基本 的 封装 性 。 尽 管 说 JavaScript 没有 真正 面向 对 象 的 方法 ,但 我 们 还 是 可 以 通过 实例 化 
的 方法 来 制造 对 象 。 
D 简单 的 生命 周期 呈现 。 最 明显 的 两 个 方法 constructor 和 destroy, 代表 了 组 件 的 挂 载 和 
御 载 过 程 。 但 除 此 之 外 ， 其 他 过 程 〈 如 更 新 时 的 生命 周期 ) 并 没有 体现 。 
口 明确 的 数据 流动 。 这 里 的 数据 指 的 是 调用 组 件 的 参数 。 一 旦 确定 参数 的 值 ， 就 会 解析 传 

进来 的 参数 ， 根 据 参 数 的 不 同 作出 不 同 的 响应 ， 从 而 得 到 泻 染 结果 。 

在 这 个 阶段 ， 前端 在 应 用 级 别 并 没有 过 多 复杂 的 交互 , 组件 化 发 展 缓慢 。 传 统 组 件 的 主要 问 
题 在 于 结构 、 样 式 与 行为 没有 很 好 地 结合 , 不 同 参数 下 的 逻辑 可 能 会 导致 不 同 的 演 染 逻辑 ， 这 时 
就 会 存在 大 量 HTML 结构 与 style 样式 的 拼装 。 比 如 ， 常 见 的 show、hide 与 toggle 方法 , 就 
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是 通过 改变 class 控制 style 来 显示 或 隐藏 。 这 样 的 逻辑 一 旦 复杂 ， 就 存在 大 量 的 DOM 操作 ， 
开发 及 维护 成 本 相当 高 。 

直到 富 客 户 端 应 用 越 来 越 多 , 传统 组 件 化 越 来 越 无 法 满足 开发 者 的 需要 , 于 是 引进 了 分 层 的 
思想 ， 此 时 就 出 现 了 MVC 架构 。View 只 关心 怎么 输出 变量 ， 所 以 就 诞生 了 各 种 各 样 的 模板 语 
言 ， 比 如 Smarty、Mustache 、Handlerbars 等 。 我 们 结合 Backbone 这 样 的 架构 一 起 使 用 。 让 模板 
本 身 可 以 承载 逻辑 ， 可 以 帮 有 我 们 解决 View 上 的 逻辑 问题 。 对 于 组 件 来 说 ， 可 以 减轻 拼装 HTML 
的 逻辑 部 分 , 将 这 一 部 分 解 耦 出 去 ,解决 了 数据 与 界面 耦合 的 问题 。 这 时 利用 模板 引擎 可 以 在 一 
定 程度 上 实现 组 件 化 ， 不 过 这 种 组 件 化 实现 的 还 是 字符 串 拼 接 级 别 的 组 件 化 。 


对 于 模板 ， 它 更 接近 HTML 表达 方式 ， 能 更 好 地 反映 应 用 的 语义 结构 ， 且 易于 从 设计 、 布 
局 和 样式 上 思考 , 但 模板 作为 一 个 DSL, 也 有 其 局 限 性 。 我 们 需要 重新 思考 到 底 什 么 才 是 组 件 的 
组 成 。 直 到 这 几 年 萌生 的 Angular， 我 们 看 到 了 在 HTML 上 定义 指令 的 方式 。 


W3C 标准 委员 会 最 近 才 将 类 似 的 思想 制定 成 了 规范 ， 称 为 Web Components。 顾 名 思 义 ， 这 
个 规范 是 想 统一 Web 端 关于 组 件 的 定义 。 它 通过 定义 Custom Elements ( 自 定义 元 素 ) 的 方式 来 
统一 组 件 。 每 个 自 定 义 元 素 可 以 定义 自己 对 外 提供 的 属性 、 方 法 , 还 有 事件 ， 内 部 可 以 像 写 一 个 
页 面 一 样 ， 专 注 于 实现 功能 来 完成 对 组 件 的 封装 。 

1-4 讲述 了 Web Components 的 4 个 组 成 部 分 : HTML Templates 定义 了 之 前 模板 的 概念 ， 
Custom Elements 定义 了 组 件 的 展现 形式 ，Shadow DOM 定义 了 组 件 的 作用 域 范围 、 可 以 圳 括 样 
式 ，HTML Imports 提出 了 新 的 引入 方式 。 
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1-4 Web Components 组 成 
Web Components 定义 了 一 切 我 们 想 要 的 组 件 化 概念 ， 现 在 还 有 polymer 这 个 库 可 实现 这 一 
套 理念 , 但 事实 上 它 还 需要 时 间 的 考验 。 因 为 诸如 如 何 包装 在 这 套 规范 之 上 的 框架 ， 如何 获得 在 
浏览 器 端的 全 部 支持 、 怎 么 与 现代 应 用 架构 相 结 合 等 问题 ， 目 前 都 还 没有 统一 的 解法 。 但 Web 
Components 的 确 为 组 件 化 开辟 了 一 条 罗马 大 道 ， 告 诉 了 我 们 组 件 化 可 以 这 样 去 做 。 
再 说 回 React， 它 的 组 件 化 是 什么 ， 又 是 怎么 样 构建 的 呢 ? 


















































18 第 1 章 ， 初 入 React 世界 





1.3.2 ”React 组 件 的 构建 


Web Components 通过 自 定 义 元 素 的 方式 实现 组 件 化 ， 而 React 的 本 质 就 是 关心 元 素 的 构成 ， 
React 组 件 即 为 组 件 元 素 。 组 件 元 素 被 描述 成 纯粹 的 JSON 对 象 ， 意 味 着 可 以 使 用 方法 或 是 类 来 
构建 。React 组 件 基 本 上 由 3 个 部 分 组 成 一 一 属性 (props )、 状 态 (state ) 以 及 生命 周期 方法 。 这 
里 我 们 从 一 张 图 来 简单 概括 React， 如 图 1-5 所 示 。 







































































React 组 件 














Render 











图 1-5 ”React 组 件 的 组 成 

React 组 件 可 以 接收 参数 ， 也 可 能 有 自身 状态 。 一 旦 接收 到 的 参数 或 自身 状态 有 所 改变 ， 
React 组 件 就 会 执行 相应 的 生命 周期 方法 , 最 后 演 染 。 整 个 过 程 完全 符合 传统 组 件 所 定义 的 组 件 
职责 。 

1. React 与 Web Components 

从 React 组 件 上 看 ， 它 与 Web Components 传达 的 理念 是 一 致 的 ， 但 两 者 的 实现 方式 不 同 : 
口 React 自 定 义 元 素 是 库 自 己 构建 的 ， 与 Web Components 规范 并 不 通用 ; 
口 React 演 染 过 程 包含 了 模板 的 概念 ， 即 1.2 节 所 讲 的 JSX; 
口 React 组 件 的 实现 均 在 方法 与 类 中 ， 因 此 可 以 做 到 相互 隔离 ， 但 不 包括 样式 ; 
口 React 引用 方式 遵循 ES6 module 标准 。 
可 以 说 ，React 还 是 在 纯 JavaScript 上 下 了 工夫 ,将 HTML 结构 彻底 引入 到 JavaScript 中 。 尽 
管 这 种 做 法 误 贬 不 一 ， 但 也 有 效 解决 了 组 件 所 要 解决 的 问题 之 一 。 

2. React 组 件 的 构建 方法 

React 组 件 基本 上 由 组 件 的 构建 方式 、 组 件 内 的 属性 状态 与 生命 周期 方法 组 成 。 在 本 节 中 ， 
我 们 先 来 讨论 创建 React 组 件 的 构建 方式 ， 而 属性 状态 与 生命 周期 会 在 后 面 再 介绍 。 
官方 在 React 组件 构建 上 提供 了 3 种 不 同 的 方法 : React.createCLass、ES6 classes 和 无 状态 
函数 (stateless function )。 我 们 使 用 1.1 节 中 的 Button 来 分 别 介绍 这 3 种 方法 。 

@ React.createCLass 


用 React.createClass 构建 组 件 是 React 最 传统 、 也 是 兼容 性 最 好 的 方法 。 在 0.14 版 本 发 布 
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之 前 ， 这 一 直 都 是 React 官方 唯一 指定 的 组 件 写 法 。 示 例 代码 如 下 : 


const Button = React.createClass({ 
getDefauLtProps() { 
return { 
color: 'blue', 
text: 'Confirm', 
}; 
}, 


render() { 
const { color, text } = this.props; 


return ( 
<button className={ btn btn-${color} }> 
<em>{text}</em> 
</button> 
); 


]); 





从 表象 上 看 , React.createClass 方法 就 是 构建 一 个 组 件 对 象 。 当 另 一 个 组 件 需要 调用 Button 
组 件 时 ， 只 用 写成 <Button />， 就 可 以 被 解析 成 React.createELement(Button) 方法 来 创建 Button 
实例 ， 这 意味 着 在 一 个 应 用 中 调用 几 次 Button ， 就 会 创建 几 次 Button 实例 。 





@ ES6 classes 


ES6 classes 的 写法 是 通过 ES6 标准 的 类 语法 的 方式 来 构建 方法 : 


import React, { Component } from 'react'; 


class Button extends Component { 
constructor(props) { 
super(props); 


static defauLtProps = { 
color: 'blue', 
text: 'Confirm', 


}; 


render() { 
const { color, text } = this.props; 


return ( 

<button className={ btn btn-${color} }> 
<em>{text}</em> 

</button> 

); 
} 

} 























这 里 的 直观 感受 是 从 调用 内 部 方法 变 成 了 用 类 来 实现 。 与 createclass 的 结果 相同 的 是 ， 调 





用 类 实现 的 组 件 会 创建 实例 对 象 。 
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再 说 起 继承 , 我 们 很 容易 联想 到 在 组 件 抽 象 过 程 中 也 可 以 使 用 继承 的 思路 。 如 果 我 们 学 过 面 
问 对 象 的 知识 , 就 知道 继承 与 组 合 的 不 同 , 它们 可 以 用 IS-A 与 HAS-A 来 区 别 。 在 实际 应 用 React 
的 过 程 中 ， 我 们 极 少 让 子 类 去 继承 功能 组 件 。 试 想 在 UI 层面 小 的 修改 就 会 影响 到 整体 交互 或 样 
式 ， 牵 一 发 而 动 全 身 ， 用 继承 来 抽象 往往 是 事倍功半 。 在 React 组 件 开 发 中 ， 第 用 的 方式 是 将 组 
件 拆 分 到 合理 的 粒度 ， 用 组 合 的 方式 合成 业务 组 件 ， 也 就 是 HAS-A 的 关系 。 但 在 高 阶 组 件 构建 
中 ， 我 们 可 以 用 反 向 继承 的 方法 来 实现 ， 具 体内 容 请 阅读 2.5 节 。 











说 明 React 的 所 有 组 件 都 继承 自 顶 层 类 React.Component。 它 的 定义 非常 简洁 ， 只 是 初始 化 了 
React.Component 方法 ， 声 明了 props、context、refs 等 ， 并 在 原型 上 定义 了 setState 和 
forceUpdate 方法 。 内 部 初始 化 的 生命 周期 方法 与 createClass 方式 使 用 的 是 同一 个 方法 
创建 的 。 具 体 解读 可 参见 3.2.2 节 。 


使 用 无 状态 函数 构建 的 组 件 称 为 无 状态 组 件 ， 这 种 构建 方式 是 0.14 版 本 之 后 新 增 的 ， 且 官 
方 颇 为 推 尝 。 示 例 代 码 如 下 : 
function Button({ color = 'bLue'，text = 'Confirm' }) { 
return ( 
<button className={ btn btn-${color} }> 
<em>{text}</em> 
</button> 
); 
} 
无 状态 组 件 只 传人 props 和 context 两 个 参数 ; 也 就 是 说 ， 它 不 存在 state， 也 没有 生命 周 
期 方法 ， 组 件 本 身 即 上 面 两 种 React 组 件 构 建 方法 中 的 render 方法 。 不 过 ， 像 propTypes 和 
defaultProps 还 是 可 以 通过 向 方法 设置 静态 属性 来 实现 的 。 


在 适合 的 情况 下 , 我 们 都 应 该 且 必 须 使 用 无 状态 组 件 。 无 状态 组 件 不 像 上 述 两 种 方法 在 调用 
时 会 创建 新 实例 ， 它 创建 时 始终 保持 了 一 个 实例 ,避免 了 不 必要 的 检查 和 内 存 分 配 ,， 做 到 了 内 部 
优化 。 

3. 用 React 实现 Tabs 组 件 


这 里 我 们 趁 热 打铁 , 运用 已 经 掌握 的 组 件 构建 方法 来 实现 一 个 组 件 。 首 先 , 用 ES6 classes 的 
写法 来 初始 化 Tabs 组 件 的 “骨架 ”: 
























































import React, { Component, PropTypes } from 'react'; 


class Tabs extends Component { 
constructor(props) { 
super (props); 


} 
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ee, 


render() { 
return <div className="ui-tabs"></div>; 


} 
}; 


export defaults Tabs; 


从 这 一 六 起 , 我 们 就 以 Tabs 组 件 为 例 慢 慢 介绍 React 组 件 的 主要 组 成 部 分 , 看 看 它 到 底 有 什 
么 不 同 之 处 。 


1.4 ”React 数据 流 


在 React 中 ， 数 据 是 自 顶 向 下 单 向 流动 的 ， 即 从 父 组 件 到 子 组 件 。 这 条 原则 让 组 件 之 间 的 关 
系 变 得 简单 旦 可 预测 。 

state 与 props 是 React 组 件 中 最 重要 的 概念 。 如 果 顶 层 组 件 初始 化 props， 那 么 React 会 向 下 
遍历 整 棵 组 件 树 ， 重 新 尝试 泻 染 所 有 相关 的 子 组 件 。 而 state 只 关心 每 个 组 件 自己 内 部 的 状态 ， 
这 些 状 态 只 能 在 组 件 内 改变 。 把 组 件 看 成 一 个 函数 ， 那 么 它 接受 了 props 作为 参数 ， 内 部 由 state 
作为 函数 的 内 部 参数 ， 返 回 一 个 Virtual DOM 的 实现 。 


1.4.1 state 


在 使 用 React 之 前 , 常见 的 MVC 框架 也 非常 容易 实现 交互 界面 的 状态 管理 ,比如 Backbone。 
它们 将 View 中 与 界面 交互 的 状态 解 看 ,一般 将 状态 放 在 Model 中 管理 。 但 在 React 没有 结合 Flux 
或 Redux 框架 前 ， 它 自身 也 同样 可 以 管理 组 件 的 内 部 状态 。 在 React 中 ， 把 这 类 状态 统一 称 为 
State。 

当 组 件 内 部 使 用 库 内 置 的 setstate 方法 时 ， 最 大 的 表现 行为 就 是 该 组 件 会 尝试 重新 渲染 。 
这 很 好 理解 ， 因 为 我 们 改变 了 内 部 状态 ， 组 件 需要 更 新 了 。 比 如 ， 我 们 实现 了 一 个 计数 器 组 件 : 


























import React, { Component } from 'react'; 


class Counter extends Component { 
constructor(props) { 
super(props); 


this.handleClick = this.handleClick.bind(this); 


this.state = { 
count: 0， 
}; 
} 
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handleClick(e) { 
e.preventDefault(); 


this.setState({ 
count: this.state.count + 1， 


}); 
} 


render() { 
return ( 
<div> 
<p>{this.state.count}</p> 
<a href="#" onClick={this.handleClick}> 更 新 </a> 
</div> 
); 
} 

} 

在 React 中 常常 在 事件 处 理 方法 中 更 新 state， 上 述 例子 就 是 通过 点 击 “ 更 新 ”按钮 不 断 地 更 
新 内 部 count 的 值 ， 这 样 就 可 以 把 组 件 内 状态 封装 在 实现 中 。 

值得 注意 的 是 ，setstate 是 一 个 异步 方法 ， 一 个 生命 周期 内 所 有 的 setState 方法 会 合并 操 
作 。 关 于 setstate 的 实现 原理 ， 请 参见 3.4 节 。 

有 了 这 个 特性 ， 让 React 变 得 充满 了 想象 力 。 我 们 完全 可 以 只 用 React 来 完成 对 行为 的 控制 、 
数据 的 更 新 和 界面 的 泻 染 。 然 而 ， 随 着 内 容 的 深入 ,我 们 并 不 推荐 开发 者 滥用 state， 过 多 的 内 部 
状态 会 让 数据 流 混 乱 ， 程 序 变 得 难以 维护 。 

我 们 再 来 看 Tabs 组 件 的 state。 从 前 一 节 的 经 验 中 得 到 两 个 可 能 的 内 部 状态 active- 
Index 和 prevIndex， 它 们 分 别 表示 当前 选中 tab 的 索引 和 前 一 次 选中 tab 的 索引 。 而 需要 特别 注 
意 的 一 点 是 ， 当 前 选中 的 索引 亦 是 组 件 本 身 需 要 的 参数 之 一 。 

这 里 我 们 针对 activeIndex 作为 state， 就 有 两 种 不 同 的 视角 。 

口 activeIndex 在 内 部 更 新 。 当 我 们 切换 tab 标签 时 ， 可 以 看 作 是 组 件 内 部 的 交互 行为 ， 被 
选择 后 通过 回调 函数 返回 具体 选择 的 索引 。 
口 activeIndex 在 外 部 更 新 。 当 我 们 切换 tab 标签 时 ， 可 以 看 作 是 组 件 外 部 在 传人 具体 的 索 

引 ， 而 组 件 就 像 “ 木 偶 ” 一 样 被 操控 着 。 

这 两 种 情形 在 React 组 件 的 设计 中 非常 常见 ,我 们 形象 地 把 第 一 种 和 第 二 种 视角 写成 的 组 件 
分 别称 为 智能 组 件 ( smart component ) 和 木偶 组 件 ( dumb component )。 

当然 ， 实现 组 件 时 ， 可 以 同时 考虑 兼容 这 两 种 。 我 们 来 看 下 Tabs 组 件 中 初始 化 时 的 实现 部 分 : 


constructor(props) { 
super(props); 




























































































const currProps = this.props; 


let activeIndex = 0; 
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if ('activeIndex' in currProps) { 
activeIndex = currProps.activeIndex; 

} else if ('defaultActiveIndex' in currProps) { 
activeIndex = currProps.defaultActiveIndex; 


} 


this.state = { 
activeIndex, 
prevIindex: activeIndex, 
}; 
} 


这 里 我 们 定义 了 两 种 state activeIndex 和 prevIndex。 


对 于 activeIndex 来 说 ， 既 可 能 来 源 于 使 用 内 部 更 新 的 defaultActiveIndex prop ， 即 我 们 
不 需要 外 组 件 控制 组 件 状 态 ， 也 可 能 来 源 于 需要 外 部 更 新 的 activeIndex prop。 如 图 1-6 所 示 ， 
我 们 只 能 通过 切换 外 组 件 的 状态 来 更 新 。 


切换 Tab: | Tab1 




















Tab1 Tab2 Tab 3 





第 一 个 Tab 里 的 内 容 
图 1-6 切换 组 件 的 状态 


不 过 , 不 论 组 件 是 内 部 更 新 还 是 外 部 更 新 , 我 们 都 需要 activeIndex 这 个 state 来 更 新 演 染 。 
那么 ， 如 何 做 到 外 部 更 新 时 让 状态 更 新 呢 ? 这 个 问题 会 在 1.6 节 中 详解 。 


这 里 ， 我 们 反复 提 到 的 props 是 不 是 就 是 指 传人 参数 呢 ? 继续 看 下 一 节 。 









































1.4.2 props 


props 是 React 中 男 一 个 重要 的 概念 ， 它 是 properties 的 缩写 。props 是 React 用 来 让 组 件 之 间 
互相 联系 的 一 种 机 制 ， 通 俗 地 说 就 像 方法 的 参数 一 样 。 在 1.2 节 中 ,我 们 已 经 接触 过 它们 了 。 


props 的 传递 过 程 ， 对 于 React 组 件 来 说 是 非常 直观 的 。React 的 单 向 数据 流 ， 主 要 的 流动 管 
道 就 是 props。props 本 身 是 不 可 变 的 。 当 我 们 试图 改变 props 的 原始 值 时 ，React 会 报 出 类 型 错 
误 的 警告 , 组 件 的 props 一 定 来 自 于 默认 属性 或 通过 父 组 件 传递 而 来 。 如 果 说 要 演 染 一 个 对 props 
加 工 后 的 值 ， 最 简单 的 方法 就 是 使 用 局 部 变量 或 直接 在 JSX 中 计算 结果 。 

我 们 在 1.4.1 节 中 讨论 了 Tabs 组 件 state 的 设置 情况 。 假 设 Tabs 组 件 的 数据 都 是 通过 data 
prop 传人 的 ， 即 <Tabs data={data} />。 那 么 ，Tabs 组 件 的 props 还 会 有 哪些 。 根 据 之 前 的 经 验 ， 
它 一 定 会 有 以 下 几 项 。 


口 className: 根 节点 的 class。 为 了 方便 覆盖 其 原始 样式 , 我 们 都 会 在 根 节点 上 定义 cLass， 
这 一 点 会 在 2.3 节 中 详细 说 明 。 
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口 classPrefix: class 前 级 。 对 于 组 件 来 说 ， 定 义 一 个 统一 的 class 前 级 ， 对 样式 与 交互 
分 离 起 了 非常 重要 的 作用 。 

口 defaultActiveIndex 和 activeIndex: 默认 的 激活 索引 ， 这 在 1.4.1 节 中 已 说 明 。 

口 onChange: 回调 函数 。 当 我 们 切换 tab 时， 外 组 件 需 要 知道 组 件 内 部 的 信息 ， 尤 其 是 当前 
tab 的 索引 号 的 信息 。 它 一 般 与 activeIndex 搭配 使 用 。 


React 为 props 同样 提供 了 默认 配置 ， 通 过 defauLtProps 静态 变量 的 方式 来 定义 。 当 组 件 被 
调用 的 时 候 ， 默 认 值 保证 泻 染 后 始终 有 值 。 在 render 方法 中 ,可 以 直接 使 用 props 的 值 来 演 染 。 
这 里 ,我 们 只 需要 默认 设置 classPrefix 和 onChange 即 可 。 因 为 defaultActiveIndex 和 active- 
Index 我 们 需要 保持 只 取 其 中 一 个 条 件 。 相 关 代码 如 下 : 

static defauLtProps = { 
classPrefix: 'tabs', 
onChange: () => {}, 

}; 

但 Tabs 组 件 的 信息 全 由 一 个 对 象 传 进来 的 方式 真 的 好 么 ”对 于 React 组 件 来 说 ， 我 们 考 
虑 设计 组 件 一 定 要 满足 一 大 原则 一 一 直观 。 把 基本 设置 与 数据 一 起 定义 成 一 个 数组 或 对 象 是 初 
学 者 最 容易 犯 的 一 个 错误 ， 如 果 说 组 件 能 够 分 解 ， 那 我 们 一 定 要 分 解 ， 并 使 用 子 组 件 的 方式 
来 处 理 。 











































































































次 仔细 观察 Tabs 组 件 在 Web 界面 的 特征 ， 一 般 来 说 ， 会 看 到 两 个 区 域 : 切换 区 域 与 内 
容 区 域 。 那 么 ， 我 们 就 定义 两 个 子 组 件 ， 其 中 TabNav 组 件 对 应 切换 区 域 ，TabContent 组 件 对 应 
内 容 区 域 。 这 两 个 区 域 组 件 都 存放 了 一 个 有 序数 组 ， 都 可 以 进一步 拆 分 。 到 这 里 ,我们 就 想得到 
两 种 组 织 的 方式 。 


口 在 Tabs 组件 内 把 所 有 定义 的 子 组 件 都 显 式 展示 出 来 ,这 种 方式 的 好 处 在 于 非常 易于 理解 ， 
可 自 定 义 能 力 强 ， 但 调用 过 程 显得 过 于 笨重 。React-Bootstrap 和 Material UI 组 件 库 中 的 
Tabs 组 件 采用 的 是 这 种 形式 。 调 用 方式 近似 如 下 形式 : 


<Tabs cLassPrefix={ tabs'} defaultActiveIndex={0}> 
<TabNav> 
<TabHead>Tab 1</TabHead> 
<TabHead>Tab 2</TabHead> 
<TabHead>Tab 3</TabHead> 
</TabNav> 
<TabContent> 
<TabPane> 第 一 个 Tab 里 的 内 容 </TabPane> 
<TabPane> 第 二 个 Tab 里 的 内 容 </TabPane> 
<TabPane> 第 三 个 Tab 里 的 内 容 </TabPane> 
</TabContent> 
</Tabs> 


口 在 Tabs 组件 内 只 显示 定义 内 容 区 域 的 子 组 件 集合 , 头 部 区 域 对 应 内 部 区 域 每 一 个 TabPane 
组 件 的 props， 让 其 在 TabNav 组 件 内 拼装 。 这 种 方式 的 调用 写法 简洁 ， 把 复杂 的 逻辑 留 
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给 了 组 件 去 实现 。Ant Design 组 件 库 中 的 Tabs 组 件 采 用 的 就 是 这 种 形式 。 调 用 方式 近似 
如 下 形式 : 





<Tabs classprefix={'tabs'} defaultActiveIndex={0}> 
<TabPane key={0} tab={'Tab 1'}> 第 一 个 Tab 里 的 内 容 </TabPane> 
<TabPane key={1} tab={'Tab 2'}> 第 二 个 Tab 里 的 内 容 </TabPane> 


<TabPane key={2} tab={'Tab 3'}> 第 三 个 Tab 里 的 内 容 </TabPane> 
</Tabs> 





在 本 章 中 , 我 们 通过 后 一 种 方式 讲解 。 基 本 的 结构 确定 后 , 我 们 需要 想 一 下 怎么 演 染 这 个 结 


构 的 内 容 。 显 然 ， 并 不 是 所 有 参数 都 由 Tabs 组 件 承 载 。 只 有 两 个 props 放 在 了 Tabs 组 件 上 ， 而 
其 他 参数 直接 放 到 TabPane 组 件 中 ， 由 它 的 父 组 件 TabContent 隐 式 对 TabPane 组 件 拼 装 。 


那么 ， 这 个 一 直 在 说 的 子 组 件 是 什么 呢 ， 我 们 到 底 怎 么 对 它 进行 拼装 泻 染 呢 ? 
1. 子 组 件 prop 


在 React 中 有 一 个 重要 且 内 置 的 prop children， 它 代表 组 件 的 子 组 件 集合 。children 可 
以 根据 传人 子 组 件 的 数量 来 决定 是 否 是 数组 类 型 。 上 述 调用 TabPane 组 件 的 过 程 , 翻译 过 来 即 是 : 















































<Tabs classPrefix={'tabs'} defaultActiveIndex={0} className="tabs-bar" 
children={[ 
<TabPane key={0} tab={'Tab 1'}> 第 一 个 Tab 里 的 内 容 </TabPane>， 
<TabPane key={1} tab={'Tab 2'}> 第 二 个 Tab 里 的 内 容 </TabPane>， 
<TabPane key={2} tab={'Tab 3'}> 第 三 个 Tab 里 的 内 容 </TabPane>， 
]} 


> 
</Tabs> 





实现 的 基本 思路 就 以 TabContent 组 件 演 染 TabPane 子 组 件 集合 为 例 来 讲 ， 其 中 演 染 TabPane 
组 件 的 方法 如 下 : 


getTabPanes() { 
Const { classPprefix, activeIndex, panels, isActive } = this.props; 


return React.Children.map(panels, (child) => { 
if (!child) { return; } 


const order = parseInt(child.props.order, 10); 
const isActive = activeIndex === order; 


return React.cloneElement(child, { 
classPrefix, 
isActive, 
children: child.props.children, 
key: “tabpane-s{forder】 ， 


上 述 代 码 讲 述 了 子 组 件 集合 是 怎么 泻 染 的 。 通 过 React.ChiLdren.map 方法 遍历 子 组 件 ， 
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将 order ( 演 染 顺序 )、isActive( 是 否 激活 tab )、children( Tabs 组 件 中 传 下 的 children ) 和 key 利 
用 React 的 cloneElement 方法 克隆 到 TabPane 组 件 中 ， 最 后 返回 这 个 TabPane 组 件 集合 。 这 也 是 
Tabs 组 件 拼装 子 组 件 的 基本 原理 。 

其 中 ，React.ChiLdren 是 React 官方 提供 的 一 系列 操作 children 的 方法 。 它 提供 诸如 map、 
forEach 、count 等 实用 函数 ， 可 以 为 我 们 处 理子 组 件 提 供 便利 。 


最 后 ，TabContent 组 件 的 render 方法 只 需要 调用 getTabPanes 方法 即 可 泻 染 : 











render() { 
return (<div>{this.getTabpanes()}</div>); 
3 
假如 我 们 把 render 方法 中 的 this.getTabPanes 方法 中 对 子 组 件 的 遍历 直接 放 进 去 ， 就 会 变 成 
如 下 形式 : 
render() { 


return (<div>{React.Children.map(this.props.children, (child) => {...})}</div>); 
; 


这 种 调用 方式 称 为 Dynamic Children (动态 子 组 件 ) 。 它 指 的 是 组 件 内 的 子 组 件 是 通过 动态 
计算 得 到 的 。 就 像 上 述 对 子 组 件 的 遍历 一 样 ， 我们 一 样 可 以 对 任何 数据 、 字 符 串 、 数 组 或 对 象 作 
动态 计算 。 

用 声明 式 编程 的 方式 来 泻 染 数据 , 这 种 做 法 和 关心 所 有 细节 的 命令 式 编 程 相 比 , 会 让 我 们 轻 
松 许多 。 当 然 , 除了 数组 的 map 因数 ,还 可 以 用 其 他 实用 的 高 阶 果 数 ， 如 reduce、filter 等 图 
数 。 值 得 注意 的 是 ， 与 map 函数 相似 但 不 返回 调用 结果 的 forEach 函数 不 能 这 么 使 用 。 


2. 组 件 props 
当然 ，React 的 强大 之 处 不 止 于 此 ， 我 们 观察 TabPane 组 件 中 的 tab prop: 


<TabPane key={0} tab={'Tab 1'}> 第 一 个 Tab 里 的 内 容 </TabPane> 


它 现在 传人 的 是 一 个 字符 串 。 那 么 ， 假 如 可 以 传人 节点 呢 ， 是 不 是 就 可 以 自 定义 tab 头 展 示 
的 形式 了 。 这 就 是 component props。 对 于 子 组 件 而 言 ， 我 们 不 仅 可 以 直接 使 用 this.props. 
children 定义 ， 也 可 以 将 子 组 件 以 props 的 形式 传递 。 一 般 我 们 会 用 这 种 方法 来 让 开发 者 定义 
组 件 的 某 一 个 prop， 让 其 具备 多 种 类 型 ， 来 做 到 简单 配置 和 自 定义 配置 组 合 在 一 起 的 效果 。 

在 Tabs 组 件 中 ， 我们 就 用 到 了 这 样 的 功能 ， 调 用 方式 如 下 所 示 : 


<Tabs classPrefix={'tabs'} defaultActiveIndex={0} className="tabs-bar"> 
<TabPane 
order="0" 
tab={<span><i. className="fa fa-home"></i>&nbsp;Home</span>}> 
第 一 个 Tab 里 的 内 容 
</TabPane> 
<TabPane 
order="1" 
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tab={<span><i. className="fa fa-book"></i>&nbsp;Library</span>}> 
第 二 个 Tab 里 的 内 容 


</TabPane> 
<TabPane 
order="2" 
tab={<span><i. className="fa fa-pencil"></i>&nbsp;Applications</span>}> 
第 三 个 Tab 里 的 内 容 
</TabPane> 
</Tabs> 


这 里 我 们 使 用 font-awesome 的 图 标 。 泻 染 后 ， 每 一 个 tab 上 的 文字 前 都 会 有 一 个 图 标 ， 如 图 
1-7 所 示 。 











从 Home Library $ Applications 


图 1-7 文字 前 加 上 了 图 标 

















当然 ,我 们 也 可 以 加 入 更 多 的 自 定义 元 素 ， 可 以 是 多 行 的 ， 其 至 可 以 插入 动态 数据 。 这 听 
上 去 有 些 复杂 , 但 实现 过 程 其 实 非常 简单 。 下 面 是 写 在 TabNav 组 件 中 简化 的 渲染 子 组 件 集 合 的 
方法 : 


getTabs() { 
const { classPrefix, activeIndex, panels } = this.props; 








return React.Children.map(panels, (child) => { 
if (!child) { return; } 


const order = parseInt(child.props.order, 10); 


let classes = classnames({ 
[‘${classPprefix}-tab‘]: true, 


[‘${classPprefix}-active’ ]: activeIndex === order, 
[‘${classPprefix}-disabled]: child.props.disabled, 
}); 
return ( 


<li>{child.props.tab}</li> 
); 
}); 
} 


其 实现 看 上 去 与 getTabPanes 方法 非常 像 , 关键 在 于 通过 遍历 TabPane 组 件 的 tab prop 来 实 
现 我 们 想 要 的 功能 。 不 论 tab 是 以 字符 串 的 形式 还 是 以 虚拟 元 素 的 形式 存在 ， 都 可 以 直接 
在 <Li> 标签 中 演 染 出 来 。 

3. 用 function prop 与 父 组 件 通信 

现在 我 们 发 现 对 于 state 来 说 , 它 的 通信 集中 在 组 件 内 部 ; 对 于 props 来 说 ， 它 的 通信 是 父 组 
件 向 子 组 件 的 传播 。 相 关 代 码 如 下 : 


handleTabClick(activeIndex) { 
Lf/ 
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this.props.onChange({activeIndex, prevIindex}); 


} 
我 们 通过 点 击 事件 handleTabclick 触发 了 onChange prop 回调 函数 给 父 组 件 必要 的 值 。 对 于 兄 
弟 组 件 或 不 相关 组 件 之 间 的 通信 ， 具 体 请 看 2.4 节 。 
4. propTypes 
众所周知 ,JavaScript 不 是 强 类 型 语言 , 我们 对 在 没有 保证 的 环境 下 写 JavaScript 已 经 习 以 为 
常 了 。 强 类 型 还 是 弱 类 型 , 正 是 一 个 开发 时 的 约束 问题 。 React 对 此 作 了 受 协 , 便 有 了 propTypes。 
propTypes 用 于 规范 props 的 类 型 与 必需 的 状态 。 如 果 组 件 定义 了 propTypes， 那 么 在 开发 环 
境 下 ， 就 会 对 组 件 的 props 值 的 类 型 作 检查 ， 如 果 传 人 的 props 不 能 与 之 匹配 ，React 将 实时 在 控 
制 台 里 报 warning。 在 生产 环境 下 ， 这 是 不 会 进行 检查 的 。 
我 们 来 分 析 下 Tabs 组 件 中 的 情况 ， 并 写 出 对 应 的 propTypes。Tabs 组 件 包 括 父 组 件 Tabs 与 
子 组 件 TabPane, 下 面 我 们 分 开 来 讨论 两 者 的 propTypes。 现 在 ,我 们 先 来 看 Tabs 组 件 的 propTypes: 
static propTypes = { 
classPrefix: React.PropTypes.string, 
className: React.PropTypes.string， 
defaultActiveIndex: React.PropTypes.number, 
activeIndex: React.PropTypes.number, 
onChange: React.PropTypes.func， 
children: React.PropTypes.oneOfType([ 
React.PropTypes.arrayOf(React.PropTypes.node), 
React.PropTypes.node， 
])， 
}; 
我 们 很 清晰 地 列举 了 所 有 可 能 的 props， 并 对 它们 的 类 型 进行 定义 。 再 来 看 看 TabPane 组 件 
的 propTypes: 







































































static propTypes = { 
tab: React.PropTypes.oneOfType([ 
React.PropTypes.string, 
React.PropTypes.node， 
]).isRequired, 
order: React.PropTypes.string.isRequired, 
disable: React.PropTypes.bool, 


}; 

在 TabPane 组 件 的 props 中 ， 对 tab 和 order prop 除了 定义 类 型 ， 还 定义 了 是 否 必要 。 因 此 ， 
如 果 在 写 TabPane 组 件 时 ， 没 有 定义 order prop， 浏 览 器 就 会 主动 报 一 个 类 型 错误 的 提示 : 

Warning: Failed propType: Required prop ‘order. was not specified in “TabPane . 

值得 注意 的 是 ， 在 propTypes 支持 的 基本 类 型 中 ， 男 数 类 型 的 检查 是 propTypes.func， 而 
不 是 propTypes.function。 对 于 布尔 类 型 的 检查 是 propTypes.booL， 而 不 是 propTypes .boolean。 
这 是 因为 function 和 boolean 在 JavaScript 里 是 关键 词 。 

propTypes 有 很 多 类 型 支持 ， 不 仅 有 基本 类 型 ， 还 包括 枚 举 和 自 定义 类 型 。 
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1.5 ” React 生命 周期 fa 


命 周 期 ( life cycle ) 的 概念 广泛 运用 于 各 行 各 业 。 从 广义 上 来 说 ， 生 命 周 期 泛 指 自然 界 和 
A 化 及 其 规律 。 自 然 界 的 生命 周期 , 可 分 为 出 生 、 成长、 成 熟 、 
a 而 不 同体 系 下 的 生命 周期 又 都 可 以 从 上 述 规律 中 演化 出 来 , 运用 到 软件 开发 的 生 
命 周期 上 ， 这 二 者 看 似 相似 ， 事 实 上 又 有 所 不 同 。 生 命 体 的 周期 是 单一 方向 不 可 逆 的 过 程 ， 而 软 
件 开 发 的 生命 周期 会 根据 方法 的 不 同 ， 在 完成 前 重新 开始 。 


React 组 件 的 生命 周期 根据 广义 定义 描述 ， 可 以 分 为 挂 载 、 演 染 和 绝 载 这 几 个 阶段 。 当 演 
后 的 组 件 需 要 更 新 时 ， 我 们 会 重新 去 泻 染 组 件 ， 直 至 件 载 。 
因此 ， 我 们 可 以 把 React 生命 周期 分 成 两 类 : 
口 当 组 件 在 挂 载 或 种 载 时 ; 
口 当 组 件 接 收 新 的 数据 时 ， 即 组 件 更 新 时 。 


















































1.5.1 ” 挂 载 或 卸载 过 程 


下 面 我 们 简要 介绍 一 下 组 件 的 挂 载 和 钊 载 过 程 。 

1. 组 件 的 挂 载 

组 件 挂 载 是 最 基本 的 过 程 , 这 个 过 程 主要 做 组 件 状 态 的 初始 化 。 我 们 推荐 以 下 面 的 例子 为 模 
板 写 初始 化 组 件 : 


import React, { Component, PropTypes } from 'react'; 


























class App extends Component { 
static propTypes = { 
a 
}; 


static defaultProps = { 
VE 
}; 


constructor(props) { 
super(props); 


this.state = { 
VO 
}; 
} 


componentWillMount() { 
/ns 
} 
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componentDidMount() { 
} 


render() { 
return <div>This is a demo.</div>; 


} 
} 


我 们 看 到 propTypes 和 defaultProps 分 别 代表 props 类 型 检查 和 默认 类 型 。 这 两 个 属性 被 声明 成 
静态 属性 ,意味 着 从 类 外 面 也 可 以 访问 它们 , 比如 可 以 这 么 访问 :App.propTypes 和 App.defauLtProps。 

之 后 会 看 到 两 个 明显 的 生命 周期 方法 ， 其 中 componentWitlMount 方法 会 在 render 方法 之 前 
执行 ， 而 componentDidMount 方法 会 在 render 方法 之 后 执行 ， 分 别 代表 了 浑 染 前 后 的 时 刻 。 

这 个 初始 化 过 程 没 什么 特别 的 ， 包 括 读 取 初始 state 和 props 以 及 两 个 组 件 生 命 周期 方法 
componentNtLLMount 和 componentDidMount， 这 些 都 只 会 在 组 件 初始 化 时 运行 一 次 。 

如 果 我 们 在 componentWtLLMount 中 执行 setState 方法 ， 会 发 生 什 么 呢 ? 组 件 会 更 新 state， 
但 组 件 只 泻 染 一 次 。 因 此 ， 这 是 无 意义 的 执行 ， 初 始 化 时 的 state 都 可 以 放 在 this. state。 

如 果 我 们 在 componentDidMount 中 执行 setSstate 方 法 ， 又 会 发 生 什么 呢 ? 组 件 当然 会 再 次 更 
新 , 不 过 在 初始 化 过 程 就 泻 染 了 两 次 组 件 ， 这 并 不 是 一 件 好 事 。 但 实际 情况 是 ， 有 一 些 场景 不 得 
不 需要 setState， 比 如 计算 组 件 的 位 置 或 宽 高 时 ， 就 不 得 不 让 组 件 先 泻 染 ， 更 新 必要 的 信息 后 ， 
再 次 泻 染 。 

2. 组 件 的 卸载 

组 件 种 载 非常 简单 ， 只 有 componentWtLLUnmount 这 一 个 纯 载 前 状态 : 


























ps 














import React, { Component, PropTypes } from 'react'; 


class App extends Component { 
componentWillUnmount() { 
ff 
} 


render() { 
return <div>This is a demo.</div>; 
} 
} 


在 componentWittunmount 方法 中 ， 我 们 常常 会 执行 一 些 清理 方法 ， 如 事件 回收 或 是 清除 定 














1.5.2 ”数据 更 新 过 程 


更 新 过 程 指 的 是 父 组 件 向 下 传递 props 或 组 件 自身 执行 setstate 方法 时 发 生 的 一 系列 更 新 
动作 。 这 里 我 们 屏蔽 了 初始 化 的 生命 周期 方法 ， 以 便 观 察 更 新 过 程 的 生命 周期 : 
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import React, { Component, PropTypes } from 'react'; 


class App extends Component { 
componentWillReceiveprops(nextProps) { 
// this.setState({}) 
} 


shouldComponentUpdate(nextProps, nextState) { 
// return true; 


} 


componentWillUpdate(nextProps, nextState) { 
py 
3 


componentDidUpdate(prevProps, prevState) { 
/ban 
} 


render() { 
return <div>This is a demo.</div>; 
} 
} 
如 果 组 件 自身 的 state 更 新 了 ， 那么 会 依次 执行 shouldComponentUpdate、componentWillUpdate 、 


render 和 componentDidUpdate。 


shouldComponentUpdate 是 一 个 特别 的 方法 ， 它 接收 需要 更 新 的 props 和 state， 让 开发 者 增加 
必要 的 条 件 判断 ， 让 其 在 需要 时 更 新 ,不 需要 时 不 更 新 。 因 此 ， 当 方法 返回 false 的 时 候 ， 组 件 
不 再 向 下 执行 生命 周期 方法 。 

shouldComponentUpdate 的 本 质 是 用 来 进行 正确 的 组 件 演 染 ,怎么 理解 呢 ?” 我 们 需要 先 从 初始 
化 组 件 的 过 程 开始 说 起 ,假设 有 如 图 1-8 所 示 的 组 件 关系 ， 它 呈 三 级 的 树 状 结构 ， 其 中 空心 圆 表 
示 已 经 演 染 的 节点 。 











图 1-8 初始 化 泻 染 结构 


当 父 节点 props 改变 的 时 候 ， 在 理想 情况 下 ， 只 需 泻 染 在 一 条 链 路 上 有 相关 props 改变 的 节 
点 即 可 ， 如 图 1-9 所 示 。 
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图 1-9 props 改变 时 React 节点 的 泻 染 路 径 


而 默认 情况 下 ，React 会 泻 染 所 有 的 节点 ， 因 为 shouLdComponentUpdate 默认 返回 true。 正 确 
的 组 件 泻 染 从 另 一 个 意义 上 说 ， 也 是 性 能 优化 的 手段 之 一 。 

值得 注意 的 是 ， 无 状态 组 件 是 没有 生命 周期 方法 的 ， 这 也 意味 着 它 没 有 shouldComponent- 
Update。 泻 染 到 该 类 组 件 时 ， 每 次 都 会 重新 泻 染 。 当 然 ， 不 少 开 发 者 在 使 用 无 状态 组 件 时 会 纠结 
这 一 点 。 为 了 更 放心 地 使 用 ， 我 们 可 以 选择 引用 Recompose 库 的 pure 方法 : 


const OptimizedComponent = pure(ExpensiveComponent); 


事实 上 ，pure 方法 做 的 事 就 是 将 无 状态 组 件 转换 成 class 语法 加 上 PureRender 后 的 组 件 。 关 
于 性 能 优化 相关 的 内 容 ， 我 们 会 在 2.6 节 中 详解 。 


componentWillUpdate 和 componentDidupdate 这 两 个 生命 周期 方法 很 容易 理解 ， 对 应 的 初始 化 
方法 也 很 容易 知道 ， 它 们 代表 在 更 新 过 程 中 泻 染 前 后 的 时 刻 。 此 时 ， 我 们 可 以 想到 component- 
WiLLLUpdate 方法 提供 需要 更 新 的 props 和 state， 而 componentDidUpdate 提供 更 新 前 的 props 和 
State 。 


这 里 需要 注意 的 是 , 你 不 能 在 componentWtLLUpdate 中 执行 setstate。 如 果 你 对 此 很 感 兴趣 ， 
想 一 探究 竟 ， 可 以 直接 跳 至 3.3 节 ， 那 里 有 更 加 深入 的 解释 。 

如 果 组 件 是 由 父 组 件 更 新 props 而 更 新 的 ， 那 么 在 shouldComponentUpdate 之 前 会 先 执行 
ea 方法 。 此 方法 可 以 作为 React 在 props 传人 后 ， 演 染 之 前 setSstate 的 

会 。 在 此 方法 中 调用 setState 是 不 会 二 次 泻 染 的 。 


回想 之 前 介绍 Tabs 组 件 实 现时 留 下 的 一 个 问题 : 如 果 Tabs 组 件 的 activeIndex prop 只 由 外 
组 件 来 更 新 ， 那 是 怎么 做 到 的 呢 ? 秘密 就 在 componentWillReceiveProps 方法 上 ， 相 关 代码 如 下 : 


ComponentWNLLLReceiveProps(nextProps) { 
if ('activeIndex' in nextProps) { 
this.setState({ 
activeIndex: nextProps.activeIndex, 
}); 
} 


这 样 的 设置 就 是 让 传 入 的 props 判断 是 否 存在 activeIndex。 如 果 用 了 activeIndex 初始 化 
组 件 ， 那 么 每 次 组 件 更 新 前 都 会 去 更 新 组 件 内 部 的 activeIndex state， 达 到 更 新 组 件 的 目的 。 
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然后 ,在 tab 点 击 事件 上 ， 对 是 否 存 在 defaultActiveIndex prop 进行 判断 即 可 达到 在 传 


入 defaultActiveIndex 时 使 用 内 部 更 新 ， 当 传人 activeIndex 时 使 用 外 部 传人 的 props 更 新 。 
相关 代码 如 下 : 








handleTabClick(activeIndex) { 
const prevIndex = this.state.activeIndex; 


if (this.state.activeIndex !== activeIndex && 
'defaultActiveIndex' in this.props) { 
this.setState({ 
activeIndex, 
prevIndex ， 


]); 


this.props.onChange({ activeIndex，prevIndex }); 
} 


1.5.3 ”整体 流程 























我 们 用 一 张 流程 图 ( 如 图 1-10 所 示 ) 来 理 清 生命 周期 方法 之 间 的 关系 ， 以 及 关键 API 调用 
的 反馈 。 





ReactDOM. 
render() 






constructor 











componentWillMount() 
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componentWillUnmount() 
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ReactDOM. 
unmountComponentAtNode( ) 


forceUpdate( ) true 








图 1-10 React 生命 周期 整体 流程 图 





34 第 1 章 初 入 React 世 界 





此 外 ， 我 们 在 1.3 节 中 提 到 用 createclass 来 构建 组 件 时 ， 和 后 命 周期 稍 有 不 同 。 这 里 我 们 对 


还 在 用 createClass 方式 的 开发 者 们 ， 简 要 说 明 方法 级 别 上 的 不 同 


， 如 图 1-11 所 示 。 





ES6 classes createClass 


static propTypes 


static defauLtProps 


constructor 
(this. state) 


componentWillMount 


componentDidMount 


componentWillUnmount 


componentWillReceiveProps 


shouldComponentUpdate 


componentWillUpdate 


componentDidUpdate 


render 











图 1-11 使 用 ES6 classes 与 createClass 构建 组 件 方 法 的 异同 
。 此 外 ，ES6 classes 中 的 静态 方 

















我 们 看 到 初始 化 方法 有 所 不 同 ， 但 生命 周期 方法 均 没 有 变化 
法 用 静态 关键 词 static 声明 即 可 ， 如 static customMethod() {} 
高 阶 组 件 (higher-order component ) 替代 。 























propTypes 


getDefaultProps 


getInitialsState 





; mixin 属性 被 移 除 ， 可 以 使 用 


在 源码 中 ， 生 命 周 期 的 调用 其 实 也 是 复 用 的 代码 。 为 推行 ECMAScript 标 准 ， 我 们 更 倾向 于 


使 用 ES6 classes 的 方式 来 构建 组 件 。 


1.6 React 与 DOM 

















前 面 已 经 介绍 完 组 件 的 组 成 部 分 了 , 但 还 缺少 最 后 一 环 , 那 训 


i 是 将 组 件 泻 染 到 真实 DOM 上 。 




















从 React 0.14 版 本 开始 ，React 将 React 中 涉及 DOM 操作 的 部 分 剥离 开 ， 目 的 是 为 了 抽象 React， 


同时 适用 于 Web 端 和 移动 端 。ReactDOM 的 关注 点 在 DOM 上 ， 











因此 只 适用 于 Web 端 。 


在 React 组 件 的 开发 实现 中 , 我 们 并 不 会 用 到 ReactDOM, 只 有 在 顶层 组 件 以 及 由 于 React 模 


型 所 限 而 不 得 不 操作 DOM 的 时 候 ， 才 会 使 用 它 。 
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1.6.1 ReactDOM 

ReactDOM 中 的 API 非常 少 ， 只 有 findDOMNode 、unmountComponentAtNode 和 render。 下 面 
我 们 就 从 API 的 角度 来 讲 讲 它们 的 用 法 。 

1. findDOMNode 

上 一 节 我 们 已 经 讲 过 组 件 的 生命 周期 ，DOM 真正 被 添加 到 HTML 中 的 生命 周期 方法 是 
componentDidMount 和 componentDidUpdate 方 法。 在 这 两 个 方法 中 , 我 们 可 以 获取 真正 的 DOM 元 
素 。React 提供 的 获取 DOM 元 素 的 方法 有 两 种 ， 其 中 一 种 就 是 ReactDOM 提供 的 ftndDOMNode : 





























DOMELement findDOMNode(ReactComponent component) 


当 组 件 被 演 染 到 DOM 中 后 ，findDOoMNode 返回 该 React 组 件 实 例 相 应 的 DOM 节点 。 它 可 以 
用 于 获取 表单 的 vatue 以 及 用 于 DOM 的 测量 。 例 如 , 假设 要 在 当前 组 件 加 载 完 时 获取 当前 DOM ， 
则 可 以 使 用 ftndDoMNode 











import React, { Component } from 'react'; 
import ReactDOM from 'react-dom'; 


class App extends Component { 
componentDidMount() { 
// this 为 当前 组 件 的 实例 
const dom = ReactDOM.findDOMNode(this); 
} 


render() {} 





如 果 在 render 中 返回 nutL， 那 么 findpoMNode 也 返回 nuLL。findDOMNode 只 对 已 经 挂 载 的 组 
件 有 效 。 

涉及 复杂 操作 时 ， 还 有 非常 多 的 原生 DOM API 可 以 用 。 但 是 需要 严格 限制 场景 ， 在 使 用 之 
前 多 问 自己 为 什么 要 操作 DOM。 

2. render 

为 什么 说 只 有 在 顶层 组 件 我 们 才 不 得 不 使 用 ReactDOM 呢 ? 这 是 因为 要 把 React 泻 染 的 
Virtual DOM 演 染 到 浏览 器 的 DOM 当中， 就 要 使 用 render 方法 了 : 











ReactComponent render( 
ReactElement element, 
DOMELement container, 
[function callback] 

) 


该 方法 把 元 素 挂 载 到 container 中 ， 并 且 返 回 element 的 实例 ( 即 refs 引用 )。 当 然 ， 如 曙 
是 无 状态 组 件 ，render 会 返回 nutl。 当 组 件 装载 完毕 时 ，callback 就 会 被 调用 。 





‘i 
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当 组 件 在 初次 演 染 之 后 再 次 更 新 时 ， React 不 会 把 整个 组 件 重新 演 染 一 次 ， 而 会 用 它 高 效 的 


DOM diff 算 法 做 局 部 的 更 新 。 这 也 是 React 最 大 的 亮 


此 外 ， 与 render 相反 ，React 还 提供 了 一 个 很 / 
印 载 操作 。 


1.6.2 ”ReactDOM 的 不 稳定 方法 


点 之 一 ! 
少 使 用 的 unmountComponentAtNode 方法 来 进行 








ReactDOM 中 有 两 个 不 稳定 方法 ， 其 中 一 个 方法 与 render 方法 颇 为 相似 。 讲 起 它 ， 还 得 从 





我 们 常用 的 Dialog 组 件 在 React 中 的 实现 讲 起 。 





我 们 先 来 回忆 一 下 Dialog 组 件 的 特点 ， 它 是 不 在 文档 流 中 的 弹出 框 ， 一 般 会 绝对 定位 在 屏幕 
的 正中 央 ， 背 后 有 一 层 半 透明 的 遮 晶 。 因 此 ， 它 往往 直接 演 染 在 document.body 下 ， 然 而 我 们 并 不 























[a 























知道 如 何在 React 组 件 外 进行 操作 。 这 就 要 从 实现 Dialog 的 思路 以 及 涉及 DOM 部 分 的 实现 讲 起 。 








这 里 我 们 引入 Portal 组 件 ， 这 是 一 个 经 典 的 实现 ， 最 初 的 实现 来 源 于 React Bootstrap 组 件 库 
中 的 Overlay Mixin， 后 来 使 用 越 来 越 广泛 。 我 们 截取 关键 部 分 的 源码 : 


import React from 'react'; 
import ReactDOM, { findDOMNode } from 'react-dom'; 





import CSSPropertyOperations from 'react/lib/CSSPropertyOperations'; 


export default class Portal extends React.Component { 


constructor() { 
fe 
} 


openPortal(props = this.props) { 
this.setState({ active: true }); 
this.renderPportal(props); 
this.props.on0pen(this.node); 

} 


closePortal(isUnmounted = false) { 
const resetPortaLState = () => { 
if (this.node) { 
ReactDOM.unmountComponentAtNode(this.node); 
document.body.removeChild(this.node); 
} 
this.portal = null; 
this.node = null; 
if (isUnmounted !== true) { 
this.setState({ active: false }); 
} 
}; 


if (this.state.active) { 
if (this.props.beforeClose) { 
this.props.beforeClose(this.node, resetPport 


alState); 
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} etLse 
resetPortaLState(); 


} 





this.props.onClose(); 
} 
} 


renderPortal(props) { 

if (!this.node) { 
this.node = document.createElement('div'); 
// 在 节点 增加 到 DOM 之 前 ,执行 CSS 防止 无 效 的 重 
this.applyClassNameAndStyle(props); 
document .body.appendChiLd(Cthis.node); 

} elLse { 
// 当 新 的 props 传 下 来 的 时 候 ， 更 新 CSS 
this.applyClassNameAndStyle(props); 

} 


下 





let children = props.children; 
// https://gist.github.com/jimfb/d99e0678e9da715ccf6454961ef04d1b 


if (typeof props.children.type === 'function') { 
children = React.cloneElement(props.children, { closePortal: this.cLosePortaL }); 
} 
this.portal = ReactDOM.unstable_renderSubtreeIntoContainer( 
this, 
children, 
this.node, 
this.props.onUpdate 
); 
} 
render() { 


if (this.props.openByClickOn) { 
return React.cloneElement(this.props.openByClickOn, { onClick: this.handleWrapperClick }); 
上 


return null; 


} 
} 


从 Portal 组 件 可 以 看 出 ,我 们 实现 了 一 个 “ 壳 ”"， 其 中 包括 触发 事件 、 演 染 的 位 置 以 及 暴露 
的 方法 ,但 它 并 不 关心 子 组 件 的 内 容 。 当 我 们 使 用 它 的 时 候 ， 可 以 这 么 写 : 


<Portal ref="myPortal"> 
<Modal title="My modal"> 
Modal content 
</Modal> 
</Portal> 


这 个 组 件 可 以 说 是 Dialog 实现 的 精髓 ， 我 们 为 Dialog 的 行为 抽象 了 Portal 这 个 父 组 件 。 
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当 调用 上 述 代码 时 ， 可 以 注意 到 在 运行 到 componentDidMount 生命 周期 方法 时 ， 最 后 调用 了 
this.renderportal() 方法 ， 这 个 方法 把 子 组 件 里 的 内 容 插 入 到 document.body 下 ， 这 就 实现 了 子 
组 件 不 在 标准 文档 流 的 泻 染 。 


























用 很 简单 ， 就 是 更 新 组 件 到 传人 的 DOM 节点 上 ， 我 们 在 这 里 使 用 它 完成 了 在 组 件 内 实现 跨 组 件 
的 DOM 操作 。 

这 个 方法 与 render 方法 很 相似 ,但 render 方法 缺少 一 个 插入 某 个 节点 的 参数 。 从 最 终 
ReactDOM 方法 实现 的 源 代码 react/src/renderers/dom/client/ReactMount.js 中 可 以 了 解 到 ， 
unstable_renderSubtreeIntoContainer 与 render 方法 对 应 调用 的 方法 如 下 。 








口 render: ReactMount. renderSubtreeIntoContainer(null, nextElLement, container, callback)。 





口 unstable_renderSubtreeIntoContainer: ReactMount._renderSubtreeIntoContainer(parentComponent, 


nextElement, container, callback)。 
源码 证 明了 我 们 的 猜想 ， 这 也 说 明了 两 者 的 区 别 在 于 是 否 传 入 父 节 点 。 


此 外 ， 另 一 个 ReactDOM 中 的 不 稳定 方法 unstable_batchedUpdates 是 关于 setState 的 更 新 
策略 ， 我 们 会 在 3.4.5 中 详细 介绍 。 








1.6.3 refs 
刚才 我 们 已 经 详 述 了 ReactDOM 的 render 方法 ,比如 我 们 演 染 了 一 个 App 组 件 到 root 节点 下 : 


const myAppInstance = ReactDOM.render(<App />, document.getElementById('root')); 
myAppInstance.doSth(); 


我 们 利用 render 方法 得 到 了 App 组 件 的 实例 ， 然 后 就 可 以 对 它 做 一 些 操作 。 但 在 组 件 内 ， 
JSX 是 不 会 返回 一 个 组 件 的 实例 的 ! 它 只 是 一 个 ReactElement ， 只 是 告诉 React 被 挂 载 的 组 件 应 
该 长 什么 样 : 

const myApp = <App />; 


refs 就 是 为 此 而 生 的 ， 它 是 React 组 件 中 非常 特殊 的 prop， 可 以 附加 到 任何 一 个 组 件 上 。 从 字 
面 意思 来 看 ,refs 即 reference, 组 件 被 调用 时 会 新 建 一 个 该 组 件 的 实例 , 而 refs 就 会 指向 这 个 实例 。 


它 可 以 是 一 个 回调 函数 ， 这 个 回调 函数 会 在 组 件 被 挂 载 后 立即 执行 。 例 如 : 


import React, { Component } from 'react'; 
























































class App extends Component { 
constructor(props){ 
super (props); 


this.handleClick = this.handleClick.bind(this); 
} 
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handleClick() { 
if (this.myTextInput !== null) { 
this.myTextInput.focus(); 
} 
} 





render() { 
return ( 
<div> 
<input type="text" ref={(ref) => this.myTextInput = ref} /> 
<input 
type="button" 
value="Focus the text input" 
onClick={this.handleClick} 
/> 
</div> 
); 
} 
} 


在 这 个 例子 里 ,我们 得 到 input 组 件 的 真正 实例 ， 所 以 可 以 在 按钮 被 按 下 后 调用 输入 框 的 
focus() 方法 。 这 个 例子 把 refs 放 到 原生 的 DOM 组 件 input 中 , 我 们 可 以 通过 refs 得 到 DOM 节 
点 ; 而 如 果 把 refs 放 到 React 组 件 ， 比 如 <TextInput />， 我 们 获得 的 就 是 TextInput 的 实例 ， 
此 就 可 以 调用 TextInput 的 实例 方法 。 

refs 同样 支持 字符 串 。 对 于 DOM 操作 ， 不 仅 可 以 使 用 findpoMNode 获得 该 组 件 DOM， 还 
可 以 使 用 refs 获得 组 件 内 部 的 DOM。 比 如 : 


import React, { Component } from 'react'; 
import ReactDOM from 'react-dom'; 
































class App extends Component { 
componentDidMount() { 
// myComp 是 Comp 的 一 个 实例 ， 因 此 需要 用 findDOMNode 转换 为 相应 的 DOM 
Const myComp = this.refs.myComp; 
const dom = findDOMNode(myComp); 
} 


render() { 
return ( 
<div> 
<Comp ref="myComp" /> 
</div> 
); 
} 
} 


要 获取 一 个 React 组 件 的 引用 , 既 可 以 使 用 this 来 获取 当前 React 组 件 , 也 可 以 使 用 refs 来 
获取 你 拥有 的 子 组 件 的 引用 。 

我 们 回 到 1.6.2 节 中 Portal 组 件 里 暴露 的 两 个 方法 openPortal 和 closePortal。 这 两 个 方法 的 
调用 方式 为 : 
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this.refs.myPortaL.openPortaL(); 
this.refs.myPortal.closeportal(); 


这 种 命令 式 调 用 的 方式 ， 
件 状态 维护 中 不 建议 用 这 种 方 
为 了 防止 内 存 泄漏 ， 当 外 

















尽管 说 并 不 是 React 推 尝 的 ， 但 我 们 仍然 可 以 使 用 。 原 则 上 ， 在 组 
me 


载 一 个 组 件 的 时 候 ， 组 件 里 所 有 的 refs 就 会 变 为 null。 





值得 注意 的 是 ，findDoMNode 和 refs 都 无 法 用 于 无 状态 组 件 中 ， 原 因 在 前 面 已 经 说 过 。 无 状 





态 组件 挂 载 时 只 是 方法 调用 ， 








如 果 需 要 访问 该 组 件 的 真实 D 
不 推荐 这 样 做 。 因 为 这 在 大 部 
中 构建 代码 。 











没有 新 建 实例 。 





对 于 React 组 件 来 说 ，refs 会 指向 一 个 组 件 类 的 实例 ， 所 以 可 以 调用 该 类 定义 的 任何 方法 。 


OM， 可 以 用 ReactDoM.findDoMNode 来 找到 DOM 节点 ， 但 我 们 并 
分 情况 下 都 打破 了 封装 性 ， 而 且 通 常 都 能 用 更 清晰 的 办 法 在 React 








1.6.4 ” React 之 外 的 DOM 操作 


DOM 操作 可 以 归纳 为 对 











DOM 的 增 、 删 、 改 、 查 。 这 里 的 “ 查 ” 指 的 是 对 DOM 属性 、 样 





式 的 查看 ,比如 查看 DOM 的 位 置 、 宽 、 高 等 信息 。 而 要 对 DOM 进行 增 、 删 、 改 , 就 要 先 到 DOM 


中 查询 元 素 。 
React 的 声明 式 泻 染 机 制 

















复杂 的 DOM 操作 抽象 为 简单 的 state 和 props 的 操作 ， 因 此 避免 


了 很 多 直接 的 DOM 操作 。 不 过 ， 仍 然 有 一 些 DOM 操作 是 React 无 法 避免 或 者 正在 努力 避免 的 。 








举 一 个 明显 的 例子 ， 如 果 


要 调用 HTML5 Audio/Video 的 play 方法 和 input 的 focus 方法 ， 








React 就 无 能 为 力 了 ， 这 时 只 能 使 用 相应 的 DOM 方法 来 实现 。 

React 提供 了 事件 绑 定 的 功能 ， 但 是 仍然 有 一 些 特殊 情况 需要 自行 绑 定 事件 ， 例 如 Popup 等 
组 件 ， 当 点 击 组 件 其 他 区 域 时 可 以 收缩 此 类 组 件 。 这 就 要 求 我 们 对 组 件 以 外 的 区 域 (一 般 指 
document 和 body ) 进行 事件 绑 定 。 例 如 : 








componentDidUpdate(prevProps, prevState) { 
if (!this.state.isActive && prevState.isActive) { 
document.removeEventListener('click', this.hidepopup); 


} 


if (this.state.isActive && !prevState.isActive) { 
document.addEventListener('click', this.hidePopup); 


} 
} 


componentWillUnmount() { 


document.removeEventListener('click', this.hidepPopup); 


} 


hidePopup(e) { 
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if (!this.isMounted()) { return false; } 





const node = ReactDOM.findDOMNode( this); 
const target = e.target || e.srcElement; 
const isInside = node.contains(target); 


if (this.state.isActive && !isInside) { 
this.setState({ 
isActive: false, 
]); 
} 
} 


React 中 使 用 DOM 最 多 的 还 是 计算 DOM 的 尺寸 ( 即位 置信 息 )。 我 们 可 以 提供 像 width 或 
height 这 样 的 工具 函数 : 








function width(eL) { 
const styles = el.ownerDocument.defaultView.getComputedStyle(el, null); 


const width = parseFloat(styles.width.indexOf('px') !== -1 ? styles.width : 0); 
const boxSizing = styles.boxSizing || 'content-box'; 
if (boxSizing === 'border-box') { 
return width; 
} 


const borderLeftWidth = parseFloat(styles.borderLeftWidth); 
const borderRightwidth = parseFloat(styles.borderRightWidth); 
const paddingLeft = parseFloat(styles.paddingLeft); 

const paddingRight = parseFloat(styles.paddingRight); 


return width - borderRightWidth - borderLeftWidth - paddingLeft - paddingRight; 
} 


但 上 述 计算 方法 并 不 能 完全 覆盖 所 有 情况 ， 这 需要 付出 不 少 的 成 本 去 实现 。 值 得 高 兴 的 是 ， 
React 正在 自己 构建 一 个 DOM 排列 模型 ， 来 努力 避免 这 些 React 之 外 的 DOM 操作 。 我 们 相信 在 
不 和 久 的 将 来 ，React 的 使 用 者 就 可 以 完全 抛弃 掉 jQuery 等 DOM 操作 库 。 

可 以 说 在 React 组 件 开 发 中 , 还 有 很 多 意料 之 外 的 情形 。 在 这 些 情形 中 , 应 该 如 何 运 用 React 
的 方式 优雅 地 解决 问题 是 我 们 需要 一 直 思 考 的 。 























1.7 组 件 化 实例 : Tabs 组 件 
前 面 我 们 穿插 介绍 了 Tabs 组 件 的 关键 实现 ， 现 在 将 把 完整 的 例子 展示 出 来 : 























import React, { Component, PropTypes, cloneElement } from 'react'; 
import classnames from 'classnames'; 
import style from './tabs.scss'; 


这 段 代码 是 最 基本 的 引用 。 除 了 引用 React 之 外 ， 还 引用 了 操作 class 的 库 classnames 以 及 
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样式 文件 。 这 归功 于 webpack 强大 的 加 载 机 制 ， 详 情 请 参考 附录 A 中 对 webpack 配置 的 讲解 。 


Tabs 组 件 的 封装 逻辑 在 之 前 已 经 讲解 得 很 清晰 了 ， 即 把 必要 的 props 克隆 到 TabNav 或 
TabContent 组 件 中 ， 并 把 它们 组 装 到 一 起 泻 染 出 来 。 


值得 注意 的 是 ， 我 们 在 Tabs 组 件 中 设计 了 切换 tab 时 的 onChange 国 数 ， 通 过 传递 onChange 
prop 到 TabNav 子 组 件 中 ， 在 子 组 件 中 完成 对 节点 上 事件 的 绑 定 ; 


class Tabs extends Component { 
static propTypes = { 
// 在 主 节点 上 增加 可 选 class 
CLassName: PropTypes.string, 
// class 前 级 
classPrefix: PropTypes.string， 
children: PropTypes.oneOfType([ 
PropTypes.arrayOf (PropTypes.node), 
PropTypes .node, 
])， 
// 默认 激活 索引 ， 组 件 内 更 新 
defaultActiveIndex: PropTypes.number ， 
// 默认 激活 索引 ， 组 件 外 更 新 
activeIndex: PropTypes.number ， 
// 切换 时 回调 溃 数 
onChange: PropTypes.func, 
}; 






































static defauLtProps = { 
classPrefix: 'tabs', 
onChange: () => {}, 
}; 


constructor(props) { 
super(props); 


// 对 事件 方法 的 绑 定 
this .handLeTabCLick = this.handleTabClick.bind(this); 


const currProps = this.props; 


let activeIndex; 

// 初始 化 activeIndex state 

if ('activeIndex' in currProps) { 
activeIndex = currProps.activeIndex; 

} else if ('defaultActiveIndex' in currProps) { 
activeIndex = currProps.defaultActiveIndex; 


} 


this.state = { 
activeIndex, 
prevIndex: activeIndex, 


}; 
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componentWillReceivePprops(nextProps) { 
// 如 果 props 传 入 activeIndex， 则 直接 更 新 
if ('activeIndex' in nextProps) { 
this.setState({ 
activeIndex: nextProps.activeIndex, 
]); 
} 
} 


handleTabClick(activeIndex) { 
const prevIndex = this.state.activeIndex; 


// 如 果 当 前 activeIndex 与 传 入 的 activeIndex 不 一 致 ， 
// 并 且 props 中 存在 defaultActiveIndex 时 ， 则 更 新 
if (this.state.activeIndex !== activeIndex && 
"defauLtActiveIndex' in this.props) { 
this.setState({ 
activeIndex, 
prevIndex， 


]); 


// 更 新 后 执行 回调 函数 ， 抛 出 当前 索引 和 上 一 次 索引 
this.props.onChange({ activeIndex，prevIndex }); 
J 
} 


renderTabNav() { 
const { classPprefix, children } = this.props; 


return ( 
<TabNav 
key="tabBar" 
classPrefix={classPrefix} 
onTabClick={this.handleTabClick} 
panels={children} 
activeIndex={this.state.activeIndex} 
/> 
); 
} 


renderTabContent() { 
const { classPprefix, children } = this.props; 


return ( 
<TabContent 
key="tabcontent" 
classPrefix={classPrefix} 
panels={children} 
activeIndex={this.state.activeIndex} 
/> 
); 
} 


render() { 
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const { className } = this.props; 
// classnames 用 于 合并 class 
const classes = classnames(className, 'ui-tabs'); 


return ( 
<div className={classes}> 
{this.renderTabNav()} 
{this.renderTabContent()} 
</div> 
); 
} 


我 们 看 到 ， 两 个 子 组 件 TabNav 和 TabContent 的 演 染 起 到 了 至 关 重要 的 作用 。 而 TabNav 组 
件 与 TabContent 组 件 处 理 的 逻辑 类 似 ， 不 同 的 是 前 者 是 从 TabPane 组 件 的 tab prop 中 取得 内 容 ， 
后 者 是 从 TabPane 组 件 的 children 中 取得 内 容 。 


我 们 来 看 一 下 TabNav 组 件 的 实现 : 


class TabNav extends Component { 
static propTypes = { 
classPrefix: React.PropTypes.string， 
panels: PropTypes.node， 
activeIndex: PropTypes.number ， 


}; 




















getTabs() { 
const { panels, classPrefix, activeIndex } = this.props; 


return React.Children.map(panels, (child) => { 
if (!child) { return; } 


const order = parseInt(child.props.order, 10); 


// 利用 class 控制 显示 和 隐藏 
let classes = classnames({ 
[‘${classPprefix}-tab’]: true, 


[‘${classPprefix}-active' ]: activeIndex === order, 
[StcLassPrefix}-disabLed ]: child.props.disabled, 
1 


let events = {}; 
if (!child.props.disabled) { 
events = { 
onClick: this.props.onTabClick.bind(this, order), 
}; 
小 


const ref = {}; 
if (activeIndex === order) { 
ref.ref = 'activeTab'; 


- 
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return ( 
<li 








role="tab" 
aria-disabled={child.props.disabled ? 'true' : 'false'} 
aria-selected={activeIndex === order? 'true' : 'false'} 


{...events} 
className={classes} 
key={order} 
{...ref} 


{child.props.tab} 
</li> 
); 
]); 
} 


render() { 
const { classPrefix } = this.props; 


const rootClasses = classnames({ 
[‘${classprefix}-bar ]: true， 
]); 


const classes = classnames({ 
[‘${classprefix}-nav’ ]: true， 


}); 


return ( 
<div className={rootClasses} role="tablist"> 
<ul className={classes}> 
{this.getTabs()} 
</ul> 
</div> 


); 






































然后 是 TabContent 组 件 , 仔细 对 比 它 与 前 者 的 不 同 。 再 次 推 殴 TabContent 组 件 中 的 getTab- 
Panes 方法 ， 看 似 简单 ， 实 则 精妙 : 


class TabContent extends Component { 
static propTypes = { 
classPrefix: React.PropTypes.string, 
panels: PropTypes.node, 
activeIndex: PropTypes.number, 


}; 


getTabPanes() { 
const { classPrefix, activeIndex, panels } = this.props; 


return React.Children.map(panels, (child) => { 
if (!child) { return; } 
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const order = parseInt(child.props.order, 10); 
const isActive = activeIndex === order; 


return React.cloneElement(child, { 
classPrefix, 
isActive, 
children: child.props.children, 
key: ‘tabpane-${order}, 

]); 


render() { 
Const { cLassPrefix } = this.props; 


const classes = classnames({ 
[‘${classPprefix}-content  ]: true， 


}); 


return ( 
<div className={classes}> 
{this.getTabpanes()} 
</div> 
); 
} 
3 


最 后 是 TabPane 组 件 ， 它 是 最 末端 的 节点 ， 只 有 最 基本 的 演 染 : 

















class TabPane extends Component { 
static propTypes = { 

tab: PropTypes.oneOfType([ 
PropTypes.string, 
PropTypes .node, 

]).isRequired, 

order: PropTypes.string.isRequired, 

disable: PropTypes.bool, 

isActive: PropTypes.bool, 


}; 


render() { 
const { classPrefix, className, isActive, children } = this.props; 


const classes = classnames({ 
[className]: className, 
[‘${classPprefix}-panel ]: true, 
[‘${classPprefix}-active  ]: isActive, 


}); 


return ( 
<div 
role="tabpanel" 
className={classes} 
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aria-hidden={!isActive}> 
{children} 
</div> 
); 
} 
} 


自 此 ，Tabs 组 件 就 开发 完毕 了 。 





1.8 小 结 








本 章 通 过 穿插 Tabs 组 件 的 实现 介绍 了 React 的 主要 概念 及 API, 为 读者 开启 了 通 向 React 的 
二天 区 


随 着 章节 的 深入 ， 我 们 会 陆续 介绍 React 高 阶 使 用 方法 、 背 后 的 运行 机 制 、 处 理 数据 的 架构 
Flux 与 Redux。 相 信和 从 现在 开始 ， 你 已 经 做 好 在 React 的 海洋 里 邀 游 的 准备 了 。 
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本 章 中 ,我们 会 从 一 个 视图 库 所 必 备 的 事件 系统 人手 , 结合 样式 处 理 、 组 件 间 抽 象 的 方法 以 
及 组 件 性 能 优化 等 ， 继 续 展开 那些 神奇 的 语法 ， 带 领 各 位 漫步 于 React 的 世界 当中 。 之 后 ， 详 述 
实际 开发 中 比较 重要 的 动画 与 自动 化 测试 。 最 后 ， 通 过 一 个 组 件 化 实例 来 总 结 本 章 的 内 容 。 

本 章 各 节 之 间 并 没有 很 强 的 关联 性 , 读者 可 以 选择 感 兴趣 的 直接 阅读 。 但 每 一 节 的 内 容 都 至 
关 重 要 ， 在 组 件 开 发 中 缺 一 不 可 ,希望 读者 可 以 在 阅读 及 练习 中 领略 它 的 非 几 之 处 。 




















2.1 事件 系统 


Virtual DOM 在 内 存 中 是 以 对 象 的 形式 存在 的 ， 如 果 想 要 在 这 些 对 象 上 添加 事件 ， 就 会 非常 
简单 。React 基于 Virtual DOM 实现 了 一 个 syntheticEvent (合成 事件 ) 层 ， 我们 所 定义 的 事件 
处 理 需 会 接收 到 一 个 syntheticEvent 对 象 的 实例 ， 它 完全 符合 W3C 标准 ， 不 会 存在 任何 下 标 
准 的 兼容 性 问题 。 并且 与 原生 的 浏览 器 事件 一 样 拥有 同样 的 接口 ， 同 样 支持 事件 的 冒 泡 机 制 , 我 
们 可 以 使 用 stopPropagation() 和 preventDefault() 来 中 断 它 。 


所 有 事件 都 自动 绑 定 到 最 外 层 上 。 如果 需 要 访问 原生 事件 对 象 , 可 以 使 用 nativeEvent 属性 。 


























2.1.1 合成 事件 的 绑 定 方式 


React 事件 的 绑 定 方式 在 写法 上 与 原生 的 HTML 事件 监听 器 属性 很 相似 ， 并 且 含 义 和 触 发 的 
场景 也 全 都 是 一 致 的 。 比 如 ， 下 面 的 JSX 代码 表示 为 按钮 添加 点 击 事件 : 


<button onClick={this.handleClick}>Test</button> 


仔细 观察 ， 我 们 会 发 现 这 种 写法 与 DOM0 级 事件 中 直接 设置 HTML 标签 属性 为 事件 处 理 器 
的 做 法 还 是 有 很 大 不 同 的 。 在 JSX 中 ， 我 们 必须 使 用 驼峰 的 形式 来 书写 事件 的 属性 名 ( 比如 
onCLick )， 而 HTML 事件 则 需要 使 用 全 部 小 写 的 属性 名 ( 比如 onctick )。 此 外 ，HTML 的 属性 
值 只 能 是 JavaScript 代码 字符 串 ， 而 在 JSX 中 ，props 的 值 则 可 以 是 任意 类 型 ， 这 里 是 一 个 函数 
指针 。 如 果 使 用 DOM0 级 事件 的 写法 ， 会 是 这 样 的 : 
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<button onclick="handleClick()">Test</button> 


React 并 不 会 像 DOM0 级 事件 那样 将 事件 处 理 器 直接 绑 定 到 HTML 元 素 之 上 。React 仅仅 是 
借鉴 了 这 种 写法 而 已 。 下 面 我 们 来 详细 看 一 下 事件 的 内 部 机 制 。 


2.1.2 合成 事件 的 实现 机 制 


在 React 底层 ， 主 要 对 合成 事件 做 了 两 件 事 : 事件 委派 和 自动 绑 定 。 

1. 事件 委派 

在 使 用 React 事件 前 ， 一 定 要 熟悉 它 的 事件 代理 机 制 。 它 并 不 会 把 事件 处 理 函 数 直接 绑 定 到 
真实 的 节点 上 ， 而 是 把 所 有 事件 绑 定 到 结构 的 最 外 层 , 使 用 一 个 统一 的 事件 监听 器 ， 这 个 事件 监 
听 器 上 维持 了 一 个 映射 来 保存 所 有 组 件 内 部 的 事件 监听 和 处 理 函 数 。 当 组 件 挂 载 或 印 载 时 ， 只 是 
在 这 个 统一 的 事件 监听 器 上 插入 或 删除 一 些 对 象 ; 当 事 件 发 生 时 , 首先 被 这 个 统一 的 事件 监听 器 
处 理 , 然后 在 映射 里 找到 真正 的 事件 处 理 函 数 并 调用 。 这 样 做 简化 了 事件 处 理 和 回收 机 制 , 效率 
也 有 很 大 提升 。 

2. 自动 绑 定 

在 React 组 件 中 ， 每 个 方法 的 上 下 文 都 会 指向 该 组 件 的 实例 ， 即 自动 绑 定 this 为 当前 组 件 。 
而 且 React 还 会 对 这 种 引用 进行 缓存 ， 以 达到 CPU 和 内 存 的 最 优化 。 在 使 用 ES6 classes 或 者 纯 
函数 时 ， 这 种 自动 绑 定 就 不 复 存 在 了 ， 我 们 需要 手动 实现 this 的 绑 定 。 

现在 我 们 来 看 儿 种 绑 定 的 方法 。 

口 bitnd 方法 。 这 个 方法 可 以 帮助 我 们 绑 定 事件 处 理 咒 内 的 this ， 并 可 以 向 事件 处 理 器 中 传 

递 参 数 ， 比 如 : 


import React, { Component } from 'react'; 

























































































class App extends Component { 
handleClick(e, arg) { 
console.log(e, arg); 


render() { 
// 通过 bind 方 法 实现 ， 可 以 传递 参数 
return <button onClick={this.handleClick.bind(this, 'test')}>Test</button>; 
} 
} 


如 果 方 法 只 绑 定 ， 不 传 参 ， 那 stage 0 草案 中 提供 了 一 个 便捷 的 方案 一 一 双 冒 号 语法 ， 其 作 
用 与 this.handleCtlick.bind(this) 一 致 ， 并 且 Babel 已 经 实现 了 该 提案 。 比 如 : 











import React, { Component } from 'react'; 





QD ECMAScrip This-Binding Syntanx， 详 见 https://github.com/zenparsing/es-function-bind。 
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class App extends Component { 
handleClick(e) { 
console. log(e); 


} 


render() { 
return <button onClick={::this.handleClick}>Test</button>; 


} 
} 


口 构造 器 内 声明 。 在 组 件 的 构造 器 内 完成 了 this 的 绑 定 ， 这 种 绑 定 方式 的 好 处 在 于 仅 需 要 
进行 一 次 绑 定 ， 而 不 需要 每 次 调用 事件 监听 器 时 去 执行 绑 定 操作 : 


import React, { Component } from 'react'; 








class App extends Component { 
constructor(props) { 
super(props); 


this.handleClick = this.handleClick.bind(this); 
} 


handleClick(e) { 
console. log(e); 


+ 


render() { 
return <button onClick={this.handleClick}>Test</button>; 


} 
} 


口 箭头 函数 。 箭头 函数 不 仅 是 函数 的 “语法 糖 ”, 它 还 自动 绑 定 了 定义 此 函数 作用 域 的 this， 
因此 我 们 不 需要 再 对 它 使 用 bind 方法 。 比 如 ， 以 下 方式 就 能 运行 : 


import React, { Component } from 'react'; 











class App extends Component { 
const handleClick = (e) => { 
console. log(e); 


]; 


render() { 
return <button onClick={this.handleClick}>Test</button>; 


或 
import React, { Component } from 'react'; 


class App extends Component { 
handleClick(e) { 
console. log(e); 


和 


render() { 
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return <button onClick={() => this.handleClick()}>Test</button> 
} 
} 


使 用 上 述 几 种 方式 ， 都 能 够 实现 在 类 定义 的 组 件 中 绑 定 this 上 下 文 的 效果 。 





2.1.3 在 React 中 使 用 原生 事件 导 
React 提供 了 很 好 用 的 合成 事件 系统 ， 但 这 并 不 意味 着 在 React 架构 下 无 法 使 用 原生 事件 。 


React 提供 了 完备 的 生命 周期 方法 , 其 中 componentDidMount 会 在 组 件 已 经 完成 安装 并 日 在 浏览 
中 存在 真实 的 DOM 后 调用 ， 此 时 我 们 就 可 以 完成 原生 事件 的 绑 定 。 比 如 : 





























import React, { Component } from 'react'; 


class NativeEventDemo extends Component { 
componentDidMount() { 
this.refs.button.addEventListener('click', e => { 
this.handleClick(e); 
]); 
} 


handleClick(e) { 
console. log(e); 


} 


componentWillUnmount() { 
this.refs.button.removeEventListener('click'); 


render() { 
return <button ref="button">Test</button>; 
} 
} 
值得 注意 的 是 ， 在 React 中 使 用 DOM 原生 事件 时 ,一定 要 在 组 件 印 载 时 手动 移 除 ， 否 则 很 
可 能 出 现 内 存 泄漏 的 问题 。 而 使 用 合成 事件 系统 时 则 不 需要 ， 因 为 React 内 部 已 经 帮 你 妥善 地 处 
理 了 [3 











2.1.4 合成 事件 与 原生 事件 混 


既然 React 合成 事件 系统 有 这 么 多 的 好 处 ， 那 是 不 是 React 中 就 不 需要 原生 事件 了 呢 ? 当然 
不 是 ， 因 为 还 有 很 多 应 用 场景 只 能 借助 原生 事件 的 帮助 才能 完成 。 比 如 ,在 Web 页 面 中 添加 一 
个 使 用 移动 设备 扫描 二 维 码 的 功能 , 在 点 击 按钮 时 显示 二 维 码 , 点 击 非 二 维 码 区 域 时 将 其 隐藏 起 
来 。 示 例 代码 如 下 : 


import React, { Component } from 'react'; 





















































class QrCode extends Component { 
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constructor(props) { 
super(props); 


this.handleClick = this.handleClick.bind(this); 
this.handleClickQr = this.handleClickQr .bind(this); 


this.state = { 
active: false, 
}; 
} 


componentDidMount() { 
document.body.addEventListener('click', e => { 
this.setState({ 
active: false, 


}); 


componentWillUnmount() { 
document .body .removeEventListener('CLick ' ); 


} 


handleClick() { 
this.setState({ 
active: !this.state.active, 


}); 
} 


handleClickQr(e) { 
e.stopPropagation(); 


} 
render() { 
return ( 
<div className="qr-wrapper"> 
<button className="qr" onClick={this.handleClick}> 二 维 码 </button> 
<div 
className="code" 
style={{ display: this.state.active ? 'block' : 'none' }} 
onClick={this.handleClickQr} 
人 
<img src="qr.jpg" alt="qr" /> 
</div> 
</div> 
); 
} 
} 








上 述 代码 的 逻辑 很 简单 ， 点击 按 钮 可 以 切换 二 维 码 的 显示 与 隐藏 ， 而 在 按钮 之 外 的 区 域 同 样 
可 以 达到 隐藏 的 效果 。 然 而 ， 我 们 无 法 在 组 件 中 将 事件 绑 定 到 body 上 ， 因 为 body 在 组 件 范围 之 
外 ， 只 能 使 用 原生 绑 定 事件 来 实现 。 
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逻辑 似乎 很 简单 ， 但 React 所 表现 的 似乎 与 你 所 想 的 并 不 一 致 ， 实 际 效 果 是 在 你 点 击 二 维 人 码 
区 域 时 二 维 码 依然 会 隐藏 起 来 。 原 因 也 很 简单 ， 就 是 React 合成 事件 系统 的 委托 机 制 ， 在 合成 事 
件 内 部 仅仅 对 最 外 层 的 容器 进行 了 绑 定 ， 并 且 依 赖 事 件 的 冒 泡 机 制 完成 了 委派 。 也 就 是 说 ,事件 
并 没有 直接 绑 定 到 dtv.qr 元 素 上 ， 所 以 在 这 里 使 用 e.stopPropagation() 并 没有 用 。 当 然 ， 解 决 
方法 也 很 简单 。 

口 不 要 将 合成 事件 与 原生 事件 混用 。 比 如 : 

componentDidMount() { 
document.body.addEventListener('click', e => { 
this.setState({ 
active: false, 


}); 
}); 





























document.querySelector('.code').addEventListener('click', e => { 
e.stopPropagation(); 
入 


componentWillUnmount() { 
document.body.removeEventListener('click'); 
document .querySeLector(' .code').removeEventListener('click'); 


} 
口 通过 e.target 判断 来 避免 。 示 例 代码 如 下 : 


componentDidMount() { 
document.body.addEventListener('click', e => { 
if (e.target && e.target.matches('div.code')) { 
return; 


} 


this.setState({ 
active: false, 
}); 
}); 
} 

所 以 , 请 尽量 避免 在 React 中 混用 合成 事件 和 原生 DOM 事件 。 另 外 , 用 reactEvent.nativeEvent. 
stopPropagation() 来 阻止 冒 泡 是 不 行 的 。 阻 止 React 事件 冒 泡 的 行为 只 能 用 于 React 合成 事件 系统 
中 ， 且 没 办 法 阻止 原生 事件 的 冒 泡 。 反之， 在 原生 事件 中 的 阻止 冒 泡 行 为 ， 却 可 以 阻止 React 合成 
事件 的 传播 。 


实际 上 ，React 的 合成 事件 系统 只 是 原生 DOM 事件 系统 的 一 个 子 集 。 它 仅仅 实现 了 DOM 
Level 3 的 事件 接口 ， 并 且 统 一 了 浏览 器 间 的 兼容 问题 。 有 些 事 件 React 并 没有 实现 ， 或 者 受 某 些 
限制 没 办 法 去 实现 ， 比 如 window 的 resize 事件 。 


对 于 无 法 使 用 React 合成 事件 的 场景 ,我 们 还 需要 使 用 原生 事件 来 完成 。 
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2.1.5 ”对 比 React 合成 事件 与 JavaScript 原生 事件 


下 面 我 们 从 4 个 方面 来 对 比 React 合成 事件 与 JavaScript 原生 事件 。 


1. 事件 传播 与 阻止 事件 传播 
浏览 需 原 生 DOM 事件 的 传播 可 以 分 为 3 个 阶段 : 事件 捕获 阶段 、 目 标 对 象 本 身 的 事件 处 理 








程序 调用 以 及 事件 骨 泡 。 事 件 捕获 会 优先 调用 结构 树 最 外 层 的 元 素 上 绑 定 的 








有 件 监 昕 器 ,然后 依 


次 向 内 调用 , 一 直 调 用 到 目标 元 素 上 的 事件 监听 器 为 止 。 可 以 在 将 e.addEventListener() 的 第 三 
个 参数 设置 为 true 时 ， 为 元 素 e 注册 捕获 事件 处 理 程序 ， 并 且 在 事件 传播 的 第 一 个 阶段 调用 。 
































此 外 ,事件 捕获 并 不 是 一 个 通用 的 技术 , 在 低 于 IE9 版 本 的 浏览 器 中 无 法 使 用 。 而 事件 冒 泡 则 与 








符合 “二 八 原则 ” 


阻止 原生 事件 传播 需要 使 月 

















事件 捕获 的 表现 相反 ， 它 会 从 目标 元 素 向 外 传播 事件 ， 由 内 而 外 直到 最 外 层 。 


可 以 看 出 , 事件 捕获 在 程序 开发 中 的 意义 并 不 大 , 更 致命 的 是 它 的 旭 
的 合成 事件 则 并 没有 实现 事件 捕获 ， 仅 仅 支 持 了 习 
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容 性 问题 。 所 以 ，React 
件 冒 泡 机 制 。 这 种 API 设计 方式 统一 而 简洁 ， 


月 e.preventDefault()， 不 过 对 于 不 支持 该 方法 的 浏览 器 (IE9 以 


下 )， 只 能 使 用 e.cancelBubble = true 来 阻止 。 而 在 React 合成 事件 中 ， 只 需要 使 用 e.prevent- 


DefautLt() 即 可 。 
2. 事件 类 型 





React 合成 事件 的 事件 类 型 是 JavaScript 原生 事件 类 型 的 一 个 子 集 。 

















3. 事件 绑 定 方式 
受到 DOM 标准 的 影响 ， 绑 定 浏览 器 原生 事件 的 方式 也 有 很 多 种 ， 具 体 如 下 所 示 。 
口 直接 在 DOM 元 素 中 绑 定 : 

<button onclick="alert(1);">Test</button> 


口 在 JavaScript 中 ， 通 过 为 元 素 的 事件 属性 赋值 的 方式 实现 绑 定 : 


el.onclick 











= e => { console.log(e); } 





口 通过 事件 监听 函数 来 实现 绑 定 : 








el.addEven 


tListener('click', () => {}, false); 


el.attachEvent('onclick', () => {}); 
相 比 而 言 ，React 合成 事件 的 绑 定 方式 则 简单 得 多 : 


<button onClick={this.handleClick}>Test</button> 


4. 事件 对 象 
原生 DOM 寻 








了 件 对 象 在 W3C 标准 和 IE 标准 下 存在 着 差异 。 在 低 版 本 的 下 浏览 器 中 ， 


/ 


EC 
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使 用 window.event 来 获取 事件 对 象 。 而 在 React 合成 事件 系统 中 ， 不 存在 这 种 兼容 性 问题 ， 在 事 
件 处 理 函 数 中 可 以 得 到 一 个 合成 事件 对 象 。 














2.2 表单 


在 Web 应 用 开发 中 , 表单 的 作用 尤为 重要 。 正 是 因为 表单 的 存在 , 才 使 得 用 户 能 够 与 Web 应 
用 进行 富 交互 。 打 开 搜 索引 擎 输入 关键 字 进 行 检 索 ， 这 个 过 程 就 是 一 次 基于 表单 的 交互 。 而 在 
React 中 ， 一 切 数据 都 是 状态 ， 当 然 也 包括 表单 数据 。 在 这 一 节 中 ， 我 们 将 讲述 React 是 如 何 处 
理 表 单 的 。 














2.2.1 应 用 表单 组 件 

HTML 表单 中 的 所 有 组 件 在 React 的 JSX 都 有 相应 的 实现 ， 只 是 它们 在 用 法 上 有 些 区 别 ， 有 
些 是 JSX 语法 上 的 ， 有 些 则 是 由 于 React 对 状态 处 理 上 导致 的 一 些 区 别 。 

1. 文本 框 


这 里 的 文本 框 包括 单行 文本 输入 框 input 以 及 多 行文 本 输入 框 textarea。 下面 先 看 一 个 关于 
这 两 种 文本 框 的 示例 : 


import React, { Component } from 'react'; 




















class App extends Component { 
constructor(props) { 
super(props); 


this.handleInputChange = this.handleInputChange.bind(this); 
this.handleTextareaChange = this.handleTextareaChange.bind(this); 


this.state = { 
inputValue: '', 
textareaValue: ''， 
}; 
3 


handleInputChange(e) { 
this.setState({ 
inputVaLue: e.target.value, 
}); 
3 


handleTextareaChange(e) { 
this.setState({ 
textareaValue: e.target.value, 
]); 
} 


render() { 
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const { inputValue, textareaValue } = this.state; 
return ( 
<div> 
<p> 单 行 输入 框 : <input type="text" value={inputValue} 
onChange={this.handleInputChange} /></p> 
<p> 多 行 输入 框 : <textarea value={textareaValue} 
onChange={this.handleTextareaChange} /></p> 
</div> 
); 
下 
} 
值得 注意 的 是 ， 我 们 可 以 看 到 ，JSX 中 的 textarea 组 件 与 类 型 为 text 的 input 组 件 的 用 法 
很 类 似 。 同 样 有 一 个 value prop 用 来 表示 表单 的 值 ， 而 在 HTML 中 textarea 的 值 则 是 通过 
children 来 表示 的 。 此 外 ， 得 益 于 JSX 语法 特性 ， 我 们 可 以 在 标签 没有 子 元 素 的 时 候 使 用 单个 
标签 自 闭合 的 语法 。 
2. 单 选 按钮 与 复 选 杠 


在 HTML 中 ， 用 类 型 为 radio 的 input 标签 表示 单 选 按钮 。 类 似 地 ， 用 类 型 为 checkbox 的 
input 标签 表示 复 选 框 。 这 两 种 表单 的 value 值 一 般 是 不 会 改变 的 ， 而 是 通过 一 个 布尔 类 型 的 
checked prop 来 表示 是 否 为 选中 状态 。 当 然 , 在 JSX 中 这 些 也 是 相同 的 , 不 过 用 法 上 还 是 有 些 区 别 。 


下 面 看 一 下 单 选 按钮 的 示例 : 


import React, { Component } from 'react'; 


























class App extends Component { 
constructor(props) { 
super (props); 


this.handeChange = this.handleChange.bind(this); 


this.state = { 
radioValue: ''， 
}; 
} 


handleChange(e) { 
this.setState({ 
radioValue: e.target.value, 
}); 
} 


render() { 
const { radioValue } = this.state; 


return ( 
<div> 
<p>gender:</p> 
<label> 
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male: 
<input 
type="radio" 
value="male" 
checked={radiovaLue === 'male'} 
onChange={this.handleChange} 
/> 
</label> 
<label> 
female: 
<input 
type="radio" 
value="female" 
checked={radioValue === 'female'} 
onChange={this.handleChange} 
/> 
</label> 
</div> 


); 
} 
} 


下 面 看 一 下 复 选 框 的 示例 : 
import React, { Component } from 'react'; 


class App extends Component { 
constructor(props) { 
super(props); 


this.handleChange = this.handleChange.bind(this); 


this.state = { 
coffee: []， 
}; 
} 


handleChange(e) { 
const { checked, value } = e.target; 
let { coffee } = this.state; 


if (checked && coffee.indexof(vaLue) === -1) { 
coffee.push(value); 
} else { 
coffee = coffee.filter(i => i !== value); 
this.setState({ 
coffee, 
]); 
} 
render() { 


const { coffee } = this.state; 
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return ( 
<div> 
<p> 请 选择 你 最 喜欢 的 咖啡 : </p> 
<label> 
<input 
type="checkbox" 
value="Cappuccino" 
checked={coffee.indexOf('Cappuccino') !== -1} 
onChange={this.handLeChange} 
/> 
Cappuccino 
</label> 
<br/> 
<label> 
<input 
type="checkbox" 
value="CafeMocha" 
checked={coffee.indexOof('CafeMocha') !== -1} 
onChange={this.handLeChange} 
/> 
CafeMocha 
</label> 
<br/> 
<LabeL> 
<input 
type="checkbox" 
value="CaffeLatte" 
checked={coffee.indexOof('CaffeLatte') !== -1} 
onChange={this.handLeChange} 
/> 
Caffe Latte 
</LabeL> 
<br/> 
<LabeL> 
<input 
type="checkbox" 
value="Machiatto" 
checked={coffee.indexOf('Machiatto') !== -1} 
onChange={this.handLeChange} 
/> 
Machiatto 
</label> 
</div> 
); 
} 
} 


如 果 之 前 没有 了 解 过 , 一定 会 对 React 的 处 理 方 式 产生 疑问 。 在 HTML 中 , 很 简单 的 单 选 按 
钮 和 复 选 框 好 像 变 得 很 复杂 了 。 确 实 ， 因 为 React 对 表单 的 状态 进行 了 控制 ， 相 应 地 多 了 一 些 处 
理 onChange 的 代码 。 另 外 ， 状 态 里 面 已 经 可 以 拿 到 复 选 框 所 表示 的 选中 值 的 列表 ， 这 一 步 在 
HTML 表单 处 理 中 同样 需要 我 们 通过 JavaScript 手动 处 理 。 
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3. Select 组 件 


在 HTML 的 select 元 素 中 , 存在 单 选 和 多 选 两 种 。 在 JSX 语 法 中 , 同样 可 以 通过 设置 select 
标签 的 multiple={true} 来 实现 一 个 多 选 下 拉 列 表 。Select 组 件 与 单 选 按钮 和 复 选 框 组 件 有 些 类 
似 。 下 面 我 们 来 看 下 React 中 select 元 素 的 用 法 : 


import React, { Component } from 'react'; 























class App extends Component { 
constructor(props) { 
super(props); 


this.handleChange = this.handleChange.bind(this); 


this.state = { 
area: '! 
}; 
} 


handleChange(e) { 
this.setState({ 
area: e.target.value, 
}); 
} 


render() { 
const { area } = this.state; 


return ( 
<select value={area} onChange={this.handleChange}> 
<option value="beijing"> 北 京 </option> 
<option value="shanghai"> 上 海 </option> 
<option value="hangzhou"> 杭 州 </option> 
</select> 
); 
} 
} 


接 下 来 ， 看 看 给 select 元 素 设置 multiple={true} 的 示例 : 
import React, { Component } from 'react'; 


class App extends Component { 
constructor(props) { 
super(props); 


this.handleChange = this.handleChange.bind(this); 
this.state = { 
area: ['beijing', 'shanghai'], 
}; 
} 


handleChange(e) { 
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const { options } = e.target; 
// 注意 ， 这 里 返回 的 options 是 一 个 对 象 ， 并 非 数 组 
const area = Object.keys(options) 
.filter(i => options[i].selected === true) 
.map(i => options[i].value); 


this.setState({ 
area, 
}); 
} 


render() { 
const { area } = this.state; 


return ( 
<select multiple={true} value={area} onChange={this.handleChange}> 
<option value="beijing"> 北 京 </option> 
<option value="shanghai"> 上 海 </option> 
<option value="hangzhou"> 杭 州 </option> 
</select> 
); 
} 


这 里 ， 我 们 再 来 对 比 一 下 React 处 理 select 的 方式 与 HTML 原生 方式 的 区 别 。 在 HTML 的 
option 组 件 中 需要 一 个 selected 属性 来 表示 默认 选中 的 列表 项 ， 而 React 的 处 理 方式 则 是 通过 
为 select 组 件 添 加 value prop 来 表示 选中 的 option ， 在 设置 了 multiple={true} 的 情况 下 ， 该 
value 值 是 一 个 数组 ， 表示 选 中 的 一 组 值 。 这 一 点 与 textarea 的 处 理 方 式 一 致 ， 这 在 一 定 程度 上 
统一 了 接口 。 

实际 上 ， 上 述 select 组 件 也 可 以 写成 下 面 这 种 形式 : 


<select multiple={true} onChange={this.handLeChange}> 


























<option value="beijing" selected={area.index0of('beijing') !== -1}> 北 京 </option> 

<option value="shanghai" selected={area.index0f('shanghai') !== -1}> 上 海 </option> 

<option value="hangzhou" selected={area.index0f('hangzhou') !== -1}> 杭 州 </option> 
</select> 


过 开发 体验 就 会 差 很 多 ， 同 时 React 也 会 报 如 下 的 警 


Warning: Use the defaultValuye or vaLue props on <select> instead of setting seLected on <option> 


2.2.2” 受 控 组 件 


读 完了 上 面 的 几 个 示例 , 你 心中 一 定 会 有 疑问 , 为何 每 一 个 <input> 或 <select> 都 要 绑 定 一 
个 change 事件 呢 ? 

在 上 面 的 示例 中 ， 每 当 表 单 的 状态 发 生变 化 时 ， 都 会 被 写 人 到 组 件 的 state 中 ， 这 种 组 件 在 
React 中 被 称 为 受 控 组 件 ( controlled ee )。 在 受 控 组 件 中 , 组 件 演 染 出 的 状态 与 它 的 value 
或 checked prop 相对 应 。React 通过 这 种 方式 消除 了 组 件 的 局 部 状态 ， 使 得 应 用 的 整个 状态 更 加 
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可 控 。React 官方 同样 推荐 使 用 受 控 表单 组 件 。 总 结 下 React 受 控 组 件 更 新 state 的 流程 : 
(1) 可 以 通过 在 初始 state 中 设置 表单 的 默认 值 。 
(2) 每 当 表 单 的 值 发 生变 化 时 ， 调 用 onchange 事件 处 理 器 。 
(3) 事件 处 理 器 通过 合成 事件 对 象 e 拿 到 改变 后 的 状态 ， 并 更 新 应 用 的 state。 
(4) setState 触发 视图 的 重新 泻 染 ， 完 成 表单 组 件 值 的 更 新 。 


















































在 React 中 ， 数 据 是 单 向 流动 的 。 从 示例 中 ， 我 们 能 看 出 来 表单 的 数据 源 于 组 件 的 state， 并 | 











通过 props 传人 ， 这 也 称 为 单 向 数据 绑 定 。 然 后 ,我 们 又 通过 onChange 事件 处 理 右 将 新 的 表单 数 
据 写 回 到 组 件 的 state， 完 成 了 双向 数据 绑 定 。 

与 原生 表单 组 件 相 比 , 受 控 组 件 的 模式 确实 复杂 了 很 多 。 每 次 表单 值 发 生变 化 时 ， 都 会 执行 
上 面 几 步 , 这 样 统一 了 组 件 内 部 状态 , 使 得 表单 的 状态 更 可 靠 。 这 也 意味 着 我 们 可 以 在 执行 最 后 
一 步 setState 前 ， 对 表单 值 进行 清洗 和 校 验 。 示 例如 下 : 


handleChange(e) { 
this.setState({ 
value: e.target.value.substring(0, 140).toUpperCase(), 
}); 
} 


上 面 的 代码 做 到 了 截取 用 户 输入 的 前 140 个 字符 ， 并 转 为 大 写 。 实 际 上 ， 在 React 内 部 拦截 
了 浏览 器 的 原生 事件 ， 这 得 益 于 Virtual DOM 以 及 合成 事件 系统 。 


























2.2.3” 非 受 控 组 件 
上 面 的 所 有 示例 都 使 用 了 React 的 受 控 组 件 来 写 ， 但 这 并 不 意味 着 它 不 支持 非 受 控 组 件 。 那 
么 什么 是 非 受 控 组 件 (uncontrolled component ) 呢 ? 


简单 地 说 ， 如 果 一 个 表单 组 件 没有 value props ( 单 选 按钮 和 复 选 框 对 应 的 是 checked prop ) 
时 ， 就 可 以 称 为 非 受 控 组 件 。 相 应 地 ， 你 可 以 使 用 defauLtvatue 和 defautLtChecked prop 来 表示 
组 件 的 默认 状态 。 下 面 通过 一 个 简单 的 示例 来 描述 非 受 控 组 件 : 


import React, { Component } from 'react'; 





























class App extends Component { 


constructor(props) { 
super(props); 


this.handleSubmit = this.handleSubmit.bind(this); 
handleSubmit(e) { 
e.preventDefault(); 


// 这 里 使 用 React 提供 的 ref prop 来 操作 DOM 
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// 当然 ， 也 可 以 使 用 原生 的 接口 ， 如 document.querySeLector 
const { value } = this.refs.name; 
console.log(value); 


} 
render() { 
return ( 
<form onSubmit={this.handleSubmit}> 
<input ref="name" type="text" defaultValue="Hangzhou" /> 
<button type="submit">Submit</button> 
</form> 
); 
} 
} 


在 React 中 ， 非 受 控 组 件 是 一 种 反 模 式 ， 它 的 值 不 受 组 件 自身 的 state 或 props 控制 。 通 常 ， 
需要 通过 为 其 添加 ref prop 来 访问 演 染 后 的 底层 DOM 元 素 。 





2.2.4 ”对 比 受 控 组 件 和 非 受 控 组 件 


受 控 组 件 与 非 受 控 组 件 到 底 各 自 有 什么 特点 和 适用 场景 呢 ? 

我 们 刚才 看 到 通过 defauLtvatLue 或 者 defauLtChecked 来 设置 表单 的 默认 值 ， 它 仅 会 被 泻 染 
一 次 ， 在 后 续 的 泻 染 时 并 不 起 作用 。 下 面 对 比 以 下 两 个 示例 。 

将 输入 的 字母 转化 为 大 写 展 示 : 








<input 
value={this. state.value} 
onChange={e => { 
this.setState({ vaLue: e.target.value.toUpperCase() }) 
}} 
/> 


直接 展示 输入 的 字母 : 








<input 
defaultValue={this.state.value} 
onChange={e => { 
this.setState({ vaLue: e.target.value.toUpperCase() }) 
}} 
/> 
在 受 控 组 件 中 , 可 以 将 用 户 输入 的 英文 字母 转化 为 大 写 后 输出 展示 , 而 在 非 受 控 组 件 中 则 不 
会 。 而 如 果 不 对 受 控 组 件 绑 定 change 事件 ， 我 们 在 文本 框 中 输入 任何 值 都 不 会 起 作用 。 多 数 情 
况 下 ， 对 于 非 受 控 组 件 ， 我 们 并 不 需要 提供 change 事件 。 通 过 上 面 的 示例 可 以 看 出 ， 受 控 组 件 
和 非 受 控 组 件 的 最 大 区 别 是 : 非 受 控 组 件 的 状态 并 不 会 受 应 用 状态 的 控制 , 应 用 中 也 多 了 局 部 组 
件 状 态 ， 而 受 控 组 件 的 值 来 自 于 组 件 的 state。 
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1. 性 能 上 的 问题 





在 受 控 组 件 中 ， 每 次 表单 的 值 发 生变 化 时 ， 都 会 调用 一 次 onchange 事件 处 理 顺 ， 这 确实 会 
有 一 些 性 能 上 的 损耗 。 虽 然 使 用 非 受 控 组 件 不 会 出 现 这 些 问 题 ， 但 仍然 不 提倡 在 React 中 使 用 非 
受 控 组 件 。 这 个 问题 可 以 通过 Flux/Redux 应 用 架构 等 方式 来 达到 统一 组 件 状态 的 目的 。 











2. 是 否 需要 事件 绑 定 
使 用 受 控 组 件 最 令 人 头疼 的 就 是 ， 我 们 需要 为 每 个 组 件 绑 定 一 个 change 



































hl 





人 件 ， 并 且 定 义 一 





个 事件 处 理 需 来 同步 表单 值 和 组 件 的 状态 ， 这 是 一 个 必要 条 件 。 当 然 ,， 在 某 些 简单 的 情况 下 ,也 





可 以 使 用 一 个 事件 处 理 器 来 处 理 多 个 表单 域 ; 


import React, { Component } from 'react'; 








class FormApp extends Component { 
constructor(props) { 
super(props); 


this.state = { 
name: '! 
age: 18， 
}; 
} 


handleChange(name, e) { 
const { value } = e.target; 
// 这 里 只 能 处 理 直 接 赋值 这 种 简单 的 情况 ， 复 杂 的 处 理 建议 使 用 switch(name) 语句 
this.setState({ 
[name]: value, 
]); 
} 


render () { 
const { name, age} = this.state; 


return ( 
<div> 
<input value={name} onChange={this.handleChange.bind(this, 'name')} /> 
<input value={age} onChange={this.handleChange.bind(this, 'age')} /> 
</div> 
); 
} 
} 


2.2.5 ”表单 组 件 的 几 个 重要 属性 
在 这 一 节 中 ， 我 们 简要 介绍 一 下 表单 组 件 的 状态 属性 和 事件 属性 。 
1. 状态 属性 
React 的 form 组 件 提供 了 几 个 重要 的 属性 ， 用 于 展示 组 件 的 状态 。 
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口 value: 类 型 为 text 的 input 组 件 、textarea 组 件 以 及 select 组 件 都 借助 value prop 来 展示 
应 用 的 状态 。 
口 checked: 类 型 为 radio 或 checkbox 的 组 件 借 助 值 为 boolean 类 型 的 selected prop 来 展示 
应 用 的 状态 。 

口 selected: 该 属性 可 作用 于 select 组 件 下 面 的 option 上 ，React 并 不 建议 使 用 这 种 方式 表 
示 状 态 ， 而 推荐 在 select 组 件 上 使 用 value 的 方式 。 


2. 事件 属性 
刚刚 提 到 的 状态 属 1 



































ne 


生 与 事件 属性 存在 一 定 的 关联 一 一 在 状态 属性 发 生变 化 时 ,会 触发 














onChange 事件 属性 。 实 际 上 ， 受 控 组 件 中 的 change 事件 与 HTML DOM 中 提供 的 input 事件 更 
为 类 似 ?。 同 样 ，React 支持 DOM Level 3 中 定义 的 所 有 表单 事件 。 








2.3 ”样式 处 理 


在 React 中 ， 人 处 理 样 式 是 至 关 重 要 的 一 环 ， 也 是 当下 非常 热门 的 话题 。 在 这 一 方 中 ， 我 们 除 


了 介绍 基本 样式 设置 之 外 ， 还 会 讲 到 现在 业界 很 火 的 CSS Modules 的 概念 及 用 法 。 





2.3.1 基本 样式 设置 





React 组 件 最 终 会 生成 HTML， 所 以 你 可 以 使 用 给 普通 HTML 设置 CSS 一 样 的 方法 来 设置 





样式 。 如 果 我 们 想 给 组 件 添加 类 名 , 为 了 避免 命名 冲突 , React 中 需要 设置 className prop。 此 外 ， 
也 可 以 通过 style prop 来 给 组 件 设置 行内 样式 ， 这 里 要 注意 style prop 需要 的 是 一 个 对 象 。 

















设置 样式 时 ， 需 要 注意 以 下 几 点 : 


口 自 定 义 组 件 建 议 支持 cLassName prop， 以 让 用 户 使 用 时 添加 自 定义 样式 ; 
口 设置 行内 样式 时 要 使 用 对 象 。 
设置 样式 的 示例 代码 如 下 : 














const style = { 
color: 'white', 
backgroundImage: ‘url(${imgUrl})., 
// 注意 这 里 大 写 的 W， 会 转换 成 -webkit-transition 
WebkitTransition: 'all', 
// ms 是 唯一 小 写 的 浏览 器 前 级 
msTransition: 'all', 
于 3 


; 
const component = <Component style={style} />; 





GD GlobalEventHandlers.oninput， 详 见 https://developer.mozilla.org/zh-CN/docs/Web/API/GlobalEventHandlers/oninput。 
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1. 样式 中 的 像素 值 


当 设置 width 和 height 这 类 与 大 小 有 关 的 样式 时 ， 大 部 分 会 以 像素 为 单位 ， 此 时 若 重 复 输 
入 px， 会 很 麻烦 。 为 了 提高 效率 ，React 会 自动 对 这 样 的 属性 添加 px。 比 如 : 





// 泻 染 成 height: 10px 
const style = { height: 10 }; 


ReactDOM. render(<Component style={style}>Hello</Component>, mountNode); 


意 ， 有 些 属性 除了 支持 px 为 单位 的 像素 值 ， 还 支持 数字 直接 作为 值 ， 此 时 React 并 不 添 
加 px， 如 LineHeight"。 


2. 使 用 classnames 库 
在 React 0.13 版 本 之 前 , React 官方 提供 Reactaddons.classSet 插件 来 给 组 件 动态 设置 cLassName， 
这 在 后 续 版 本 中 被 移 除 (为 了 精简 API )。 我 们 可 以 使 用 classnames 库 来 操作 类 


如 果 不 使 用 classnames 库 ， 就 需要 这 样 处 理 动态 类 名 : 


import React, { Component } from 'react'; 























class Button extends Component { 


L/P es 
render() { 
Let btnClass = 'btn'; 


if (this.state.ispressed) { btnClass += ' btn-pressed'; } 
else if (this.state.isHovered) { btnClass += ' btn-over'; } 


return <button className={btnClass}>{this.props.label}</button>; 


} 
}; 


使 用 了 classnames 库 代 码 后 ， 就 可 以 变 得 很 简单 : 


import React, { Component } from 'react'; 
import classNames from 'classnames'; 








class Button extends Component { 
Lf ss 
render() { 
const btnClass = classNames({ 
'btn': true, 
'btn-pressed': this.state.ispressed, 
'btn-over': !this.state.ispressed && this.state.isHovered, 


}); 


return <button className={btnClass}>{this.props.label}</button>; 


} 
}); 








GD Shorthand for Specifying Pixel Values in style props, 详 见 https:/facebook.github.io/reacttips/style-props-value-px.html。 
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2.3.2 CSS Modules 


CSS 是 前 端 领域 中 进化 最 慢 的 一 块 。 由 于 ES6 的 快速 普及 以 及 Babel 与 webpack 等 工具 的 迅 
猛 发 展 ， 相 较 于 JavaScript ，CSS 被 远 远 甩 在 了 后 面 ， 逐 渐 成 为 各 类 大 型 项 目 工 程 化 的 痛 点 ， 也 
变 成 了 前 端 走向 彻底 模块 化 前 必须 要 解决 的 一 个 难题 。 

CSS 模块 化 的 解决 方案 有 很 多 ， 但 主要 有 两 类 。 

D Inline Style。 这 种 方案 彻底 抛弃 CSS， 使 用 JavaScript 或 JSON 来 写 样 式 ， 能 给 CSS 提供 

JavaScript 同样 强大 的 模块 化 能 力 。 但 缺点 同样 明显 ，Inline Style 几乎 不 能 利用 CSS 本 身 
的 特性 ， 比 如 级 联 、 媒 体 查 询 (media query ) 等 ，:hover 和 :active 等 伪 类 处 理 起 来 比较 
复杂 。 另 外 ， 这 种 方案 需要 依赖 框架 实现 ， 其 中 与 React 相关 的 有 Radium 、jsxstyle 和 
react-style。 

口 CSS Modules。 依 旧 使 用 CSS ， 但 使 用 JavaScript 来 管理 样式 依赖 。CSS Modules 能 最 大 

化 地 结合 现 有 CSS 生态 和 JavaScript 模块 化 能 力 ， 其 API 非常 简洁 ， 学 习 成 本 几乎 为 零 。 
发 布 时 依旧 编译 出 单独 的 JavaScript 和 CSS 文件 。 现 在 ，webpack css-loader 内 置 CSS 
Modules 功能 。 

下 面 我 们 详细 介绍 一 下 CSS Modules 。 

1. CSS 模块 化 遇 到 了 哪些 问题 ? 

CSS 模块 化 重要 的 是 解决 好 以 下 两 个 问题 : CSS 样式 的 导入 与 导出 。 灵 活 按 需 导 入 以 便 复 用 
代码 ， 导出 时 要 能 够 隐藏 内 部 作用 域 ,以 免 造 成 全 局 污染 。Sass、Less 、PostCSS 等 试图 解决 CSS 
编程 能 力 弱 的 问题 ， 但 这 并 没有 解决 模块 化 这 个 问题 。Facebook 工程 师 Vjeux 抛 出 了 React 开发 
中 遇 到 的 一 系列 CSS 相关 问题 ， 结 合 实际 开发 的 问题 有 以 下 几 点 。 

口 全 局 污染 : CSS 使 用 全 局 选择 器 机 制 来 设置 样式 ， 优 点 是 方便 重 写 样式 。 缺 点 是 所 有 的 
样式 都 是 全 局 生效 ， 样 式 可 能 被 错误 覆盖 ， 因 此 产生 了 非常 丑陋 的 !important， 其 至 
inline !important 和 复杂 的 选择 器 权重 计数 表 "”， 提 高 犯错 概率 和 使 用 成 本 。 Web 
Components 标准 中 的 Shadow DOM 能 彻底 解决 这 个 问题 ， 但 它 把 样式 彻底 局 部 化 ， 造 成 
外 部 无 法 重 写 样 式 ， 损 失 了 灵活 性 。 

口 命名 混乱 : 由 于 全 局 污染 的 问题 ， 多 人 协同 开发 时 为 了 避免 样式 冲突 ， 选 择 器 越 来 越 复 

杂 ， 容 易 形成 不 同 的 命名 风格 ， 很 难 统一 。 样 式 变 多 后 ， 命 名 将 更 加 混乱 。 

口 依赖 管理 不 彻底 : 组 件 应 该 相互 独立 ， 引 入 一 个 组 件 时 ， 应 该 只 引入 它 所 需要 的 CSS 样 
式 。 现 在 的 做 法 是 除了 要 引入 JavaScript， 还 要 再 引入 它 的 CSS， 而 且 Saas/Less 很 难 实现 
对 每 个 组 件 都 编译 出 单独 的 CSS， 引 入 所 有 模块 的 CSS 又 造成 浪费 。JavaScript 的 模块 化 
已 经 非常 成 熟 ， 如 果 能 让 JavaScript 来 管理 CSS 依赖 是 很 好 的 解决 办 法 ， 而 webpack 的 
css-loader 提供 了 这 种 能 力 。 




















































































































QD Calculating a selector’s specificity, 详 见 https:/www.w3.org/TR/selectors/#specificity。 
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口 无 法 共享 变量 : 复杂 组 件 要 使 用 JavaScript 和 CSS 来 共同 处 理 样式 ， 就 会 造成 有 些 变量 
在 JavaScript 和 CSS 中 元 余 ， 而 预 编 译 语言 不 能 提供 跨 JavaScript 和 CSS 共享 变量 的 这 种 
能 力 。 

口 代码 压缩 不 彻底 : 由 于 移动 端 网 络 的 不 确定 性 ， 现 代 工 程 项 目 对 CSS 压缩 的 要 求 已 经 到 
了 变态 的 程度 。 很 多 压缩 工具 为 了 节省 一 个 字 节 ,会 把 16px 转 成 lpc， 但 是 这 对 非常 长 的 
类 名 却 无 能 为 力 。 

上 述 问题 只 任 CSS 自身 是 无 法 解决 的 , 如 果 通 过 JavaScript 来 管理 CSS, 就 很 好 解决 。 因此 ， 
Vjuex 给 出 的 解决 方案 是 完全 的 CSS ipJS", 但 这 相当 于 完全 抛弃 CSS , 在 JavaScript 中 以 hash 映 
射 来 写 CSS， 但 这 种 做 法 未 免 有 些 激 进 ， 直 到 出 现 了 CSS Modules。 

2. CSS Modules 模块 化 方案 


CSS Modules 内 部 通过 ICSS 来 解决 样式 导入 和 导出 这 两 个 问题 ， 分 别 对 应 :import 
和 :export 两 个 新 增 的 伪 类 : 













































































:import("path/to/dep.css") { 
localAlias: keyFromDep; 
/a 

} 


:export { 
exportedKey: exportedValue; 
/* ... */ 

} 




















但 直接 使 用 这 两 个 关键 字 编 程 太 烦 琐 ， 项 目 中 很 少 会 直接 使 用 它们 ， 我 们 需要 的 是 用 
JavaScript 来 管理 CSS 的 能 力 。 结 合 webpack 的 css-loader ， 就 可 以 在 CSS 中 定义 样式 ,在 
JavaScript 文件 中 导入 。 


@ 启用 CSS Modules 
启用 CSS Modules 的 代码 如 下 : 





// webpack.config.js 
css?moduLes&LocaLIdentName=[name]_ [LocaL]-[hash:base64:5] 

















加 上 modules 即 为 启用 ， 其 中 LocaLIdentName 是 设置 生成 样式 的 命名 规则 。 
下 面 我 们 直接 看 看 怎么 引用 CSS，webpack 又 是 怎么 转化 class 名 的 : 























/* components/Button.css */ 
.normaL { /* normal 相关 的 所 有 样式 */ } 
.disabled { /* disabled 相关 的 所 有 样式 */ } 


将 以 上 CSS 保存 好 ， 然 后 用 import 的 方法 在 JavaScript 文件 中 引用 : 








QD React: CSS in JS - NationJS ， 详 见 http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs. html。 
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/* components/Button.js */ 
import styles from './Button.css'; 


console.log(styles); 

// => 

// Object { 

// normal: 'button--normal-abc5436', 

// disabled: 'button--disabled-def884', 


// } 


buttonELem.outerHTML = “<button class=${styles.normal}>Submit</button>. 
我 们 看 到 ， 最 终生 成 的 HTML 是 这 样 的 : 


<button class="button--normal-abc5436"> Processing... </button> 





注意 到 button- -normaL-abc5436 是 CSS Modules 按照 LocaLIdentName 自动 生成 的 class 名 
称 ， 其 中 abc5436 是 按照 给 定 算法 生成 的 序列 码 。 经 过 这 样 混淆 处 理 后 ，class 的 名 称 基本 就 是 
佳 一 的 , 大 大 降低 了 项 目 中 样式 覆盖 的 几率 。 同时 在 生产 环境 下 修改 规则 , 生成 更 短 的 class 名 ， 
可 以 提高 CSS 的 压缩 率 。 
CSS Modules 对 CSS 中 的 class 名 都 做 了 处 理 ， 使 用 对 象 来 保存 原 class 和 混淆 后 class 的 
对 应 关系 。 通 过 这 些 简单 的 处 理 ，CSS Modules 实现 了 以 下 几 点 : 
口 所 有 样式 都 是 局 部 化 的 ， 解 决 了 命名 冲突 和 全 局 污染 问题 ; 
D ctLass 名 的 生成 规则 配置 灵活 ， 可 以 以 此 来 压缩 class 名 ; 
口 只 需 引 用 组 件 的 JavaScript， 就 能 搞定 组 件 所 有 的 JavaScript 和 CSS ; 
口 依然 是 CSS ， 学 习 成 本 几乎 为 零 。 
@ 样式 默认 局 部 
使 用 了 CSS Modules 后 , 就 相当 于 给 每 个 class 名 外 加 了 :local, 以 此 来 实现 样式 的 局 部 化 。 
果 我 们 想 切 换 到 全 局 模式 ， 可 以 使 用 :global 包裹 。 示 例 代 码 如 下 : 
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.normal { 
color: green; 


} 


/* 以 上 与 下 面 等 价 */ 
:local(.normal) { 
color: green; 


} 


/* 定义 全 局 样式 */ 
:global(.btn) { 
color: red; 


} 


/* 定义 多 个 全 局 样式 */ 
:global { 
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.Link { 
color: green; 
} 
.box { 
color: yellow; 
} 
} 


@ 使 用 composes 来 组 合 样式 
对 于 样式 复 用 , CSS Modules 只 提供 了 唯一 的 方式 来 处 理 








composes 组合 。 示例 代码 如 下 : 


/* components/Button.css */ 


.base { /* 所 有 通用 的 样式 */ } 


.Normal { 

composes: base; 

/* normal 其 他 样式 */ 
} 


.disabled { 
composes: base; 
/* disabled 其 他 样式 */ 


import styles from './Button.css'; 

buttonElem.outerHTML = “<button class=${styles.normal}>Submit</button>. 

生成 的 HTML 变 为 : 

<button class="button--base-abc53 button--normaL-abc53"> Processing... </button> 
由 于 在 .normal 中 组 合 了 .base， 所 以 编译 后 的 normal 会 变 成 两 个 class。 
此 外 ， 使 用 composes 还 可 以 组 合 外 部 文件 中 的 样式 : 

/* settings.css */ 

.primary-color { 


color: #f40; 
} 




















/* components/Button.css */ 


.base { /* 所 有 通用 的 样式 */ } 


.primary { 
composes: base; 
composes: S$primary-color from './settings.css'; 
/* primary 其 他 样式 */ 

} 


对 于 大 多 数 项 目 ， 有 了 composes 后 ， 已 经 不 再 需要 预 编译 处 理 器 了 。 但 如 果 想 用 的 话 ， 由 








于 composes 不 是 标准 的 CSS 语法 ， 编 译 时 会 报错 ， 此 时 就 只 能 使 用 预 处 理 器 自己 的 语法 来 做 样 
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式 复 用 了 。 

@ class 命名 技巧 

CSS Modules 的 命名 规范 是 从 BEM 扩展 而 来 的 。BEM 把 样式 名 分 为 3 个 级 别 ， 有 具体 如 下 
所 示 。 


口 Block: 对 应 模块 名 ， 如 Dialog。 
口 Element: 对 应 模块 中 的 节点 名 Confirm Button。 
口 Modifier: 对 应 节点 相关 的 状态 ， 如 disabled 和 highlight。 
BEM 最 终 得 到 的 class 名 为 dialog confirm-button--highlight。 使 用 双 符 号 _ 和 -- 是 为 
了 与 区 块 内 单词 间 的 分 隔 符 区 分 开 来 。 虽 然 看 起 来 有 些 奇特 , 但 BEM 被 非常 多 的 大 型 项 目 采用 。 
CSS Modules 中 CSS 文件 名 恰好 对 应 Block 名 , 只 需要 再 考虑 Element 和 Modifier 即 可 。 BEM 
对 应 到 CSS Modules 的 做 法 是 : 


/* .dialog.css */ 
.ConfirmButton--disabled {} 


我 们 也 可 以 不 遵循 完整 的 命名 规范 ， 使 用 小 驼峰 的 写法 把 Block 和 Modifier 放 到 一 起 : 


/* .dialog.css */ 
.disabledConfirmButton {} 


@ 实现 CSS 与 JavaScript 变量 共享 
上 面 提 到 的 :export 关键 字 可 以 把 CSS 中 的 变量 输出 到 JavaScript 中 ， 例 如 : 










































































/* config.scss */ 
Sprimary-color: #f40; 


:export { 
primaryColor: S$primary-color; 


} 


/* app:js */ 
import style from 'config.scss'; 


// 会 输出 #F40 


console.log(style.primaryColor); 

3. CSS Modules 使 用 技巧 

CSS Modules 是 对 现 有 的 CSS 做 减法 。 为 了 追求 简单 可 控 ， 作 者 建议 遵循 如 下 原则 : 
口 不 使 用 选择 器 ， 只 使 用 class 名 来 定义 样式 ; 

口 不 层 闭 多 个 class， 只 使 用 一 个 class 把 所 有 样式 定义 好 ; 

口 所 有 样式 通过 composes 组 合 来 实现 复 用 ; 

口 不 扔 套 。 
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其 中 前 两 条 原则 相当 于 削弱 了 样式 中 最 灵活 的 部 分 , 初学 者 很 难 接受 。 第 一 条 实践 起 来 难度 
不 大 ， 但 第 二 条 中 模块 状态 过 多 时 ，ctLass 数量 将 成 倍 上 升 。 

上 上 面 之 所 以 说 “建议 ”， 是 因为 CSS Modules 并 不 强制 我 们 一 定 要 这 人 么 做 。 这 上 听 起 来 有 些 矛 
盾 。 由 于 多 数 CSS 项 目 存 在 深厚 的 历史 遗留 问题 ， 过 多 的 限制 就 意味 着 增加 迁移 成 本 和 与 外 部 
合作 的 成 本 。 初 期 使 用 肯定 需要 一 些 折 中 。 幸 运 的 是 ，CSS Modules 这 点 做 得 很 好 。 下 面 我 们 来 
列举 一 些 常见 问题 。 

(1) 如 果 我 对 一 个 元 素 使 用 多 个 class 呢 ? 

样式 照样 生效 。 

(2) 如 果 我 在 一 个 style 文件 中 使 用 同名 class 呢 ? 

这 些 同 名 class 编译 后 虽然 可 能 是 随机 码 ， 但 仍 是 同名 的 。 

(3) 如 果 我 在 style 文件 中 使 用 了 id 选择 器 、 伪 类 和 标签 选择 器 等 呢 ? 

所 有 这 些 选 择 需 将 不 被 转换 ， 原 封 不 动 地 出 现在 编译 后 的 CSS 中。 也 就 是 说 ，CSS Modules 
只 会 转换 class 名 相关 的 样式 。 

4. CSS Modules 结合 历史 遗留 项 目 实践 

好 的 技术 方案 除了 功能 强大 、 炫 酷 ， 还 要 能 做 到 现 有 项 目 能 平滑 迁移 ，CSS Modules 在 这 一 
点 上 表现 得 非常 灵活 。 

@ 外 部 如 何 履 盖 局 部 样式 

当 生 成 混淆 的 class 名 后 ， 可 以 解决 命名 冲突 ， 但 因为 无 法 预知 最 终 的 class 名 ， 不 能 通过 
一 般 选 择 器 履 盖 。 我 们 现在 在 项 目 中 的 实践 是 可 以 给 组 件 关键 节点 加 上 data-role 属性 , 然后 通过 













































































// dialog.js 
return ( 
<div className={styles.root} data-role="dialog-root"> 
<a className={styles.disabledConfirm} data-role="dialog-confirm-btn">Confirm</a> 
</div> 
); 
// dialog.css 
[data-role="dialog-root"] { 


// override style 


} 

因为 CSS Modules 只 会 转变 类 选择 器 ， 所 以 这 里 的 属性 选择 器 不 需要 添加 :global。 

@ 如 何 与 全 局 样式 共存 

前 端 项 目 不 可 避免 地 会 引入 normalize.css 或 其 他 一 类 全 局 CSS 文件 , 使 用 webpack 可 以 让 全 局 
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样式 和 CSS Modules 的 局 部 样式 和 谐 共 存 。 下 面 是 具体 项 目 中 使 用 的 webpack 部 分 配置 代码 : 


module: { 

loaders: [{ 
test: /\.jsx?$/, 
loader: 'babel', 

生计 
test: /\.scss$/, 
exclude: path.resoLve(_ dirname, 'src/styles'), 
loader: 'styLelcss?moduLes&LocaLIdentName=[name]_ [LocaL]!sass?sourceMap=true ' ， 








}, 
test: /\.scss$/, 
include: path.resoLve(_ dirname， 'src/styles'), 
loader: 'style!css!sass?sourceMap=true', 
}] 
} 


/* src/app:js */ 
import './styles/app.scss'; 
import Component from './view/Component' 


/* src/views/Component.js */ 
import './Component.scss'; 


目录 结构 如 下 : 


STC 

| 一 appjs 
| 一 styles 
| 上 一 app.ScSS 
| 


[一 normalize.scss 
[一 views 


FF- 一 Component.js 
-一 Component.scss 





这 样 所 有 全 局 的 样式 都 放 到 src/styles/app.scss 中 引入 就 可 以 了 ， 其 他 所 有 目录 (包括 
src/views ) 中 的 样式 都 是 局 部 的 。 

CSS Modules 很 好 地 解决 了 CSS 目前 面临 的 模块 化 难题 。 支 持 与 预 编译 语言 搭配 使 用 ,能 
分 利用 现 有 技术 ， 同 时 也 能 和 全 局 样式 灵活 搭配 。CSS Modules 的 实现 也 属 轻 量 级 ， 未 来 有 标准 
解决 方案 后 ， 可 以 低 成 本 迁移 。 

5. CSS Modules 结合 React 实践 

在 cLassName 处 直接 使 用 CSS 中 的 class 名 即 可 : 


/* dialog.css */ 
.root {} 

.confirm {} 
.disabledConfirm {} 




















/* dialog.js */ 
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import React, { Component } from 'react'; 
import classNames from 'classnames'; 
import styles from './dialog.css'; 


class Dialog extends Component { 
render() { 
const cx = classNames({ 
confirm: !this.state.disabled, 
disabledConfirm: this.state.disabled, 
]); 





return ( 
<div className={styles.root}> 
<a className={styles[cx]}>Confirm</a> 
</div> 
); 
} 
} 


注意 ,一 般 把 组 件 最 外 层 节 点 对 应 的 class 名 称 为 root。 

React 本 身 处 理 样 式 与 其 他 View 库 并 没有 太 多 区 别 ， 主 要 是 直接 操作 样式 或 是 操作 
classname 间接 操作 样式 的 不 同 黑 了 。 而 与 CSS Modules 的 深度 结合 可 能 是 React 的 一 大 特点 。 想 
象 一 下 CSS 模块 化 的 远景 ， 我 们 离 成 熟 的 Web 组 件 化 梦想 的 道路 越 来 越 近 了 。 

如 果 不 想 频繁 地 输入 styles.**， 可 以 使 用 react-css-modules 库 。 它 通过 高 阶 组 件 的 形式 来 
避免 重复 输入 styles.**。 我 们 来 重 写 上 述 例子 : 























import React, { Component } from 'react'; 
import classNames from 'classnames'; 

import CSSModules from 'react-css-modules'; 
import styles from './dialog.css'; 


class Dialog extends Component { 
render() { 
const cx = classNames({ 
confirm: !this.state.disabled, 
disabledConfirm: this.state.disabled, 
]); 


return ( 
<div styleName="root"> 
<a styleName={cx}>Confirm</a> 
</div> 
); 
} 
} 


export default CSSModules(Dialog, styles); 
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此 外 ， 对 比 原始 的 CSS Modules， 有 以 下 几 个 优点 : 

口 我 们 不 用 再 关注 是 否 使 用 驼峰 来 命名 class 名 ; 

D 我 们 不 用 每 一 次 使 用 CSS Modules 的 时 候 都 关联 style 对 象 ; 

口 使 用 CSS Modules , 容易 使 用 :global 去 解决 特殊 情况 ,使 用 react-css-modules 可 写成 <div 
className="global-css"” styleName="local-module"></div>， 这 种 形式 轻松 对 应 全 局 和 局 
部 ; 

口 当 styleName 关联 了 一 个 undefined CSS Modules 时 ， 我 们 会 得 到 一 个 警告 ; 

口 我 们 可 以 强迫 使 用 单一 的 CSS Modules。 









































2.4 组 件 间 通信 


React 是 以 组 合 组 件 的 形式 组 织 的 ， 组 件 因为 彼此 是 相互 独立 的 ， 从 传递 信息 的 内 容 上 看 ， 
几乎 所 有 类 型 的 信息 都 可 以 实现 传递 ， 例 如 字符 串 、 数 组 、 对 象 、 方 法 或 自 定义 组 件 等 。 所 以 ， 
在 由 套 关系 上 ,就 会 有 3 种 不 同 的 可 能 性 : 父 组 件 疝 子 组 件 通信 、 子 组 件 向 父 组 件 通信 和 没有 髓 
套 关系 的 组 件 之 间 通 信 。 

接 下 来 , 我 们 会 重点 讨论 这 3 种 不 同 的 通信 方式 。 其 中 在 父 组 件 向 子 组 件 通信 后 ， 我 们 还 扩 
展 了 一 种 特殊 形式 一 一 跨 级 组 件 通信 。 
























































2.4.1 父 组 件 向 子 组 件 通 信 


这 种 方式 在 1.4 节 中 已 经 有 较为 详细 的 说 明 ，React 数据 流动 是 单 向 的 ， 父 组 件 向 子 组 件 的 
通信 也 是 最 常见 的 方式 。 父 组 件 通过 props 向 子 组 件 传递 需要 的 信息 。 我 们 通过 一 个 列表 组 件 
List， 并 将 其 中 的 项 抽象 成 ListItem 组 件 来 温习 这 个 过 程 : 


import React, { Component } from 'react'; 





























function ListItem({ value }) { 
return ( 
<li> 
<span>{value}</span> 
</li> 
); 
} 


function List({ list, title }) { 
return ( 
<div> 
<ListTitle title={title} /> 
<ul> 
{list.map((entry, index) => ( 
<ListItem key={ "list-${index}.} value={entry.text} /> 
))} 
</ul> 
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</div> 
); 
} 


当 我 们 需要 传递 每 一 个 ListItem 的 值 时 ， 先 通过 向 List 传递 一 个 数组 ， 然 后 遍历 数组 中 的 值 
传递 给 子 组 件 ListItem 来 完成 泻 染 。 


2.4.2 子 组 件 向 父 组 件 通信 
在 用 React 之 前 的 组 件 开 发 模式 时 ， 和 常常 需要 接收 组 件 运行 时 的 状态 ， 这 时 我 们 常用 的 方法 
有 以 下 两 种 。 


口 利用 回调 函数 : 这 是 JavaScript 灵活 方便 之 处 ， 这 样 就 可 以 拿 到 运行 时 状态 。 
口 利用 自 定义 事件 机 制 : 这 种 方法 更 通用 ， 使 用 也 更 广泛 。 设 计 组 件 时 ， 考 虑 加 入 事件 机 
制 往 往 可 以 达到 简化 组 件 API 的 目的 。 
在 React 中 ， 子 组 件 向 父 组 件 通信 可 以 使 用 上 面 的 任意 一 种 方法 ， 但 在 这 种 简单 的 场景 下 利 
用 自 定义 事件 显然 过 于 复杂 ， 为 了 达到 目的 ， 一般 会 选择 较为 简单 的 方法 。 
现在 我 们 在 ListItem 组 件 上 加 上 checkbox， 并 要 求 勾 选 动作 触发 后 把 选中 的 项 暴露 出 来 : 


import React, { Component } from 'react'; 










































































class ListItem extends Component { 
static defauLtProps = { 
text: '', 
checked: false, 


. 


render() { 
return ( 
<li> 
<input type="checkbox" checked={this.props.checked} 
onChange={this.props.onChange} /> 
<span>{this.props.value}</span> 
</li> 
); 
3 
} 


class List extends Component { 
static defauLtProps = { 
list: []， 
handleItemChange: () => {}, 
}; 


constructor(props) { 
super(props); 


this.state = { 
list: this.props.list.map(entry => ({ 
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text: entry.text, 
checked: entry.checked, 
})), 
}; 
} 


onItemChange(entry) { 
const { list } = this.state; 


this.setState({ 
list: list.map(prevEntry => ({ 
text: prevEntry.text, 
checked: prevEntry.text === entry.text ? 
!prevEntry.checked : prevEntry.checked, 
})), 
}); 


this.props.handleItemChange(entry); 
} 


render() { 
return ( 
<div> 
<ul> 
{this.state.list.map((entry, index) => ( 
<ListItem 
key={ list-${index}.} 
value={entry. text} 
checked={entry.checked} 
onChange={this.onItemChange.bind(this, entry)} 





在 上 述 例子 中 ， 我们 在 List 组 件 中 构造 了 handtleItemChange 方法 ， 这 样 在 使 用 List 组 件 时 ， 
就 可 以 在 运行 时 拿 到 改变 的 项 对 应 的 值 。 比 如 : 


import React, { Component } from 'react'; 


class App extends Component { 
constructor(props) { 
super(props); 


this.handleItemChange = this.handleItemChange.bind(this); 
} 


handleItemChange(item) { 
// console.log(item); 
} 
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render() { 
return ( 
<List 
list={[{text: 1}, {text: 2}]} 
handleItemChange={this.handleIltemChange} 


/> 


); 
} 
| 
观察 一 下 实现 方法 ,可 以 发 现 它 与 传统 回调 函数 的 实现 方法 一 样 。 在 前 端 开发 过 程 中 ,， 普 适 
的 方法 在 任何 库 或 框架 下 都 是 适用 的 。 此 外 ， 我 们 看 到 setstate 一 般 与 回调 函数 均 会 成 对 出 现 ， 


这 是 因为 回调 函数 即 是 转换 内 部 状态 时 的 函数 传统 。 






































2.4.3” 跨 级 组 件 通信 

当 需 要 让 子 组 件 跨 级 访问 信息 时 , 我 们 可 以 像 之 前 说 的 方法 那样 向 更 高 级 别 的 组 件 层 层 传递 
props， 但 此 时 的 代码 显得 不 那么 优雅 ， 甚 至 有 些 宛 余 。 在 React 中 ， 我 们 还 可 以 使 用 context 来 
实现 跨 级 父子 组 件 间 的 通信 : 

class ListItem extends Component { 


static contextTypes = { 
color: PropTypes.string, 


}; 











render() { 
const { value } = this.props; 


return ( 
<li style={{background: this.context.color}}> 
<span>{value}</span> 
</li> 
); 
} 
} 


class List extends Component { 
static childContextTypes = { 
color: PropTypes.string, 


}; 


getChildContext() { 
return { 
color: 'red', 
}; 
} 


render() { 
const { list } = this.props; 
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return ( 
<div> 
<ListTitle title={title} /> 
<ul> 
{list.map((entry, index) => ( 
<ListItem key={ list-${index}.} value={entry.text} /> 
))} 
</ul> 
</div> 
); 
} 
} 


可 以 看 到 ， 我们 并 没有 给 ListItem 传递 props， 而 是 在 父 组 件 中 定义 了 ChildContext， 这 样 从 
这 一 层 开始 的 子 组 件 都 可 以 拿 到 定义 的 context， 例 如 这 里 的 color。 


事实 上 ，context 一 直 存 在 于 React 的 源码 中 , 但 直到 React 0.14 版 本 才 被 正式 记录 在 官方 文 
档 里 。 不 过 React 官方 并 不 建议 大 量 使 用 context， 因 为 尽管 它 可 以 减少 逐 层 传递 ,但 当 组 件 结 
构 复 杂 的 时 候 ， 我 们 并 不 知道 context 是 从 哪里 传 过 来 的 。Context 就 像 一 个 全 局 变量 一 样 ， 而 
全 局 变量 正 是 导致 应 用 走向 混乱 的 罪魁 祸首 之 一 , 给 组 件 带 来 了 外 部 依赖 的 副作用 。 在 大 部 分 情 
况 下 ， 我 们 并 不 推荐 使 用 context 。 使 用 context 比较 好 的 场景 是 真正 意义 上 的 全 局 信息 且 不 会 
更 改 ， 例 如 界面 主题 、 用 户 信息 等 。 


Redux 作者 Dan Abramov 对 于 这 个 不 稳定 的 属性 总 结 了 一 个 非常 有 意思 的 cheatsheet: 


function shouldIUseReactContextFeature() { 
if (amILirarayAuthor() && doINeedToPassSomethingDownDeepLy()) { 
// 一 个 自 定义 的 <option> 组 件 可 能 想 与 它 的 <select> 对 话 
// 这 是 可 以 的 ， 但 要 记 住 ， 这 是 一 个 实验 性 的 API， 如 果 在 一 些 情况 下 不 能 更 新 成 功 ， 
// 那么 可 能 需要 回 滚 更 改 它 
return amIFineWith(API_CHANGES && BUGGY_UPDATES ) ; 
} 






























































if (myUseCase === 'theming' || myUseCase === 'localization') { 
// 在 应 用 中 ，context 一 般 用 于 不 太 会 改变 的 全 局 变量 
// 如 果 你 坚持 使 用 它 ， 可 以 提供 一 个 高 阶 组 件 
// 当 我 们 要 更 改 这 个 API 的 时 候 ， 只 需要 改 一 个 地 方 就 可 以 了 
return tiPromtseToNWriteHOCInstead0fUsingItDirectLy(); 

} 


if (libraryAskMeToUseContext()) { 
// 向 它们 提供 一 个 高 阶 组 件 
throw new Error('File an issue with this library.'); 


} 


// 祝 你 好 运 
return yolo(); 


} 


因此 ,总 体 的 原则 是 如 果 我 们 真 的 需要 它 , 那么 建议 写成 高 阶 组 件 来 实现 。 有 关 高 阶 组 件 的 
内 容 ， 在 2.5 节 中 就 会 讲 到 。 
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2.4.4 ”没有 骨 套 关系 的 组 件 通 信 
没有 概 套 关系 的 , 那 只 能 通过 可 以 影响 全 局 的 一 些 机 制 去 考虑 。 刚才 讲 到 的 自 定义 事件 机 币 
不 失 为 一 种 上 佳 的 方法 。 


我 们 在 处 理事 件 的 过 程 中 需要 注意 ， 在 componentpidMount 事件 中 ， 如 果 组 件 挂 载 完 成 ， 再 
订阅 事件 ， 当 组 件 卸 载 的 时 候 ， 在 componentWittunmount 事件 中 取消 事件 的 订阅 。 Bl 


我 们 就 以 常用 的 发 布 /订阅 模式 来 举例 ， 这 里 借用 Nodejs Events 模块 的 浏览 器 版 实现 。 


对 于 React 使 用 的 场景 来 说 ，EventEmitter 只 需要 单 例 就 可 以 了 ， 因 此 我 们 需要 单独 初始 化 
EventEmitter 实例 : 














一 

















import { EventEmitter } from "events ' ; 


export default new EventEmitter(); 
然后 把 EventEmitter 实例 输出 到 各 组 件 中 使 用 : 


import ReactDOM from "react-dom ' ; 
import React, { Component, PropTypes } from 'react'; 
import emitter from './events'; 


class ListItem extends Component { 
static defauLtProps = { 
checked: false, 


} 


constructor(props) { 
super(props); 


render() { 
return ( 

<li> 
<input type="checkbox" checked={this.props.checked} onChange={this.props.onChange} /> 
<span>{this.props.value}</span> 

</li> 

); 
} 

} 


class List extends Component { 
constructor(props) { 
super(props); 


this.state = { 
list: this.props.list.map(entry => ({ 
text: entry.text, 
checked: entry.checked || false, 
})), 
}; 
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} 


onItemChange(entry) { 
const { list } = this.state; 


this.setState({ 
list: list.map(prevEntry => ({ 
text: prevEntry.text, 
checked: prevEntry.text === entry.text ? 
!prevEntry.checked : prevEntry.checked, 
})) 
}); 


emitter.emit('ItemChange', entry); 


} 


render() { 
return ( 
<div> 
<ul> 
{this.state.list.map((entry, index) => ( 
<ListItem 
key={ “list-${index}.} 
value={entry. text} 
checked={entry.checked} 
onChange={thils.onItemChange.bind(this, entry)} 


} 


class App extends Component { 
componentDidMount() { 
this.itemChange = emitter.on('ItemChange', (data) => { 
console.log(data); 
}); 
J 


componentWillUnmount() { 
emitter.removeListener(this.itemChange); 


} 


render() { 
return ( 
<List list={[{text: 1}, {text: 2}]} /> 
); 
} 
} 





为 了 方便 开发 者 对 比 ， 这 里 还 是 借用 上 述 例 子 ， 尽 管 是 有 








关系 的 ， 但 原理 





日 量 





EXE “ 


致 的 。 
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_ 般 情况 下 ， 组 件 之 间 的 通信 尽 可 能 保持 简洁 。 如 果 说 程序 中 出 现 多 级 传递 或 跨 级 传递 时 ， 
那么 首先 要 重新 审视 “下 是 否 有 更 合理 的 方式 。Pub/Sub 模式 实现 的 过 程 非常 容易 理解 ， 即 利用 
全 局 对 象 来 保存 事件 ， 用 广播 的 方式 去 处 理事 件 。 这 种 常规 的 设计 方法 在 软件 开发 中 处 处 可 见 ， 
但 这 种 模式 带 来 的 问题 就 是 涩 辑 关系 混乱 。 
在 上 述 几 种 通信 模式 中 , 跨 级 通信 往往 是 反 模式 的 典型 案例 。 对 于 应 用 开发 来 说 , 应 该 尽力 
如 免 仅仅 通过 例如 PubySub 实现 的 设计 思路 ， 加 入 强 依赖 与 约定 来 进一步 梳理 流程 是 更 好 的 方 时 中 
法 ， 这 将 在 第 4 章 再 深入 讨论 。 


2.5 组 件 间 抽 象 


在 React 组 件 的 构建 过 程 中 ， 和 常常 有 这 样 的 场景 ， 有 一 类 功能 需要 被 不 同 的 组 件 公 用 ， 此 时 
就 涉及 抽象 的 话题 。 在 不 同 的 设计 理念 下 ， 有 许多 的 抽象 方法 ， 而 针对 React， 我 们 重点 讨论 两 
种 : mixin 和 高 阶 组 件 。 












































2.5.1 mixin 
首先 ， 我 们 就 从 mixin 的 来 源 和 含义 来 解说 如 何 抽象 公共 方法 。 
1. 使 用 mixin 的 缘由 


mixin 的 特性 一 直 广 泛 存在 于 各 种 面向 对 和 象 语言 中 。 尤其 在 脚本 语言 中 , 大 都 有 原生 的 支持 ， 
比如 Perl、Ruby、Python， 甚 至 连 Sass 也 支持 。 先 来 看 一 个 在 Ruby 中 使 用 mixin 的 简单 例子 : 


module D 
def initialize(name) 
Gname = name 
end 
def to_s 
QName 
end 
end 








module Debug 
include D 
def who_am i? 
"#{self.class.name} (\##{self.object id}): #{self.to_s}" 
end 
end 


class Phonograph 
include Debug 
# ... 

end 


class EightTrack 
include Debug 
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ph = Phonograph.new("West End Blues") 

et = EightTrack.new("Real Pillow") 

puts ph.who_am i? # Phonograph (#-72640448): West End Blues 
puts et.who_am i? # EightTrack (#-72640468): Real Pillow 


在 Ruby 中 ，include 关键 词 即 是 mixin， 是 将 一 个 模块 混入 到 一 个 男 一 个 模块 中 ,或 是 一 个 
类 中 。 为 什么 编程 语言 要 引入 这 样 一 种 特性 呢 ? 事实 上 , 包括 C++ 等 一 些 年 龄 较 大 的 OOP 语言 ， 
它们 都 有 一 个 强大 但 危险 的 多 重 继承 特性 。 现 代 语 言 为 了 权 衔 利弊 ,大 都 舍弃 了 多 重 继承 ， 只 采 
用 单 继 承 , 但 单 继承 在 实现 抽象 时 有 诸多 不 便 之 处 。 为 了 弥补 缺失 , Java 引入 了 接口 (interface )， 
其 他 一 些 语言 则 引入 了 像 mixin 的 技巧 , 方法 虽然 不 同 , 但 都 是 为 创造 一 种 类 似 多 重 继承 的 效果 ， 
事实 上 说 它 是 组 合 更 为 贴切 。 

在 ECMAScript 历史 中 ,并 没有 严格 的 类 实现 ， 早 期 YUI、MooTools 这 些 类 库 中 都 有 自己 封 
装 类 的 实现 ， 并 引入 了 mixin 混用 模块 的 方法 。 直 到 今天 ，ES6 引入 class 语法 ， 各 种 类 库 也 在 
向 着 标准 化 靠拢 。 

2. 封装 mixin 方法 
看 到 这 里 ， 我 们 已 经 知道 了 广义 的 mixin 方法 的 作用 ， 现 在 试 着 自己 封装 一 个 mixin 方法 来 


或 受 一 下 : 























混 


5 


const mixin = function(obj, mixins) { 
const new0bj = obj; 
newObj.prototype = Object.create(obj.prototype); 


for (let prop in mixins) { 
if (mixins.hasOwnProperty(prop)) { 
new0bj.prototype[prop] = mixins[prop]; 
} 
} 


return newObj ; 


} 


const BigMixin = { 
fly: () => { 
console.log('I can fly'); 
} 
}; 


const Big = function() { 
console.log('new big'); 


}; 
const FlyBig = mixin(Big, BigMixin); 


const flyBig = new FlyBig(); // => 'new big' 
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flyBig.fly(); // => 'I can fly' 


对 于 广义 的 mixin 方 法， 就 是 用 赋值 的 方式 将 mixin 对 象 里 的 方法 都 挂 载 到 原 对 象 上 ， 来 实 
现 对 对 象 的 混入 。 


看 到 上 述 实 现 ， 是 否 会 联想 到 underscore 库 中 的 extend 或 lodash 库 中 的 assign 方法 , 或 者 
说 ES6 中 的 0bject.assign() 方法 ? 它 的 作用 是 什么 呢 ? MDN 上 的 解释 是 把 任意 多 个 源 对 象 所 
拥有 的 自身 可 枚 举 属性 复制 给 目标 对 象 ， 然 后 返回 目标 对 象 。 


因为 JavaScript 这 门 语言 比较 特别 ， 在 没有 提 到 ES6 classes 之 前 ， 并 没有 真正 的 类 ， 仅 是 用 
方法 去 模拟 对 象 ， 其 中 new 方法 用 于 创建 实例 。 正 因为 对 类 的 支持 或 限制 这 样 弱 ， 它 才 会 那么 灵 
活 ， 上 述 mixin 的 过 程 就 像 复制 对 和 象 一 样 


那 问 题 是 组 件 中 的 mixin 也 是 这 样 的 吗 ? 
3. 在 React 中 使 用 mixin 
React 在 使 用 createclass 构建 组 件 时 提供 了 mixin 属性 ， 比 如 官方 封装 的 pureRenderMixin: 
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import React from 'react'; 
import PureRenderMixin from 'react-addons-pure-render-mixin'; 


React.createClass({ 
mixins: [PureRenderMixin], 


render() { 
return <div>foo</div>; 
} 
]); 
在 createClass 对 象 参 数 中 传人 数组 mixtns， 里 面 封装 了 我 们 所 需要 的 模块 。mitxins 数组 也 
可 以 增加 多 个 mixin ， 其 每 一 个 mixin 方法 之 间 的 有 重合 ， 对 于 普通 方法 和 生命 周期 方法 是 有 所 
区 分 的 。 
在 不 同 的 mixin 里 实现 两 个 名 字 一 样 的 普通 方法 ， 按 理 说 ， 后 面 的 方法 应 该 会 覆盖 前 面 的 方 
法 。 那 么 ,在 React 中 是 否 一 样 会 覆盖 呢 ? 事实 上 ， 它 并 不 会 覆盖 ， 而 是 在 控制 台 里 报 了 一 个 在 
ReactCLassInterface 里 的 错误 ， 指 出 你 尝试 在 组 件 中 多 次 定义 一 个 方法 ， 这 会 造成 冲突 。 因 此 ， 
在 React 中 是 不 允许 出 现 重 名 普通 方法 的 mixin。 
如 果 是 React 生命 周期 定义 的 方法 ， 则 会 将 各 个 模块 的 生命 周期 方法 至 加 在 一 起 顺序 执行 。 
我 们 看 到 ， 使 用 createClass 实现 的 mixin 为 组 件 做 了 两 件 事 。 
口 工具 方法 。 这 是 mixin 的 基本 功能 ， 如 果 你 想 共 享 一 些 工 具 类 方法 ,就 可 以 定义 它们 ， 直 
接 在 各 个 组 件 中 使 用 。 
口 生命 周期 继承 ，props 与 state 合并 。 这 是 mixin 特别 重要 的 功能 ， 它 能 够 合并 生命 周期 方 
法 。 如 果 有 很 多 mixin 来 定义 componentDidMount 这 个 周期 ， 那 么 React 会 非常 智能 地 将 
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它们 都 合并 起 来 执行 。 同 样 ，mixin 也 可 以 作用 在 getInitialstate 的 结果 上 ， 作 state 的 
合并 ， 而 props 也 是 这 样 合 并 的 。 


4. ES6 Classes 与 decorator 


然而 ， 使 用 我 们 推荐 的 ES6 classes 形式 构建 组 件 时 ， 它 并 不 支持 mixin。React 文档 中 也 未 
能 给 出 解决 方法 , 但 如 此 重要 的 特性 没有 解决 方案 , 也 是 一 件 令 人 十 分 困扰 的 事情 ,为 了 可 以 使 
用 这 个 强大 的 功能 ,我 们 还 得 想 想 是 否 有 其 他 方法 , 可 以 用 来 达到 重用 模块 的 目的 , 先 回归 到 ES6 
classes ， 我 们 来 想 想 如 何 封 装 mixin。 

要 在 class 的 基础 上 封装 mixin， 就 要 说 到 class 的 本 质 。ES6 并 没有 改变 JavaScript 面向 对 象 
方法 基于 原型 的 本 质 ， 不 过 在 此 之 上 提供 了 一 些 语法 糖 ，class 就 是 其 中 之 一 。 

对 于 实现 mixin 方法 来 说 ， 这 就 没什么 不 一 样 了 。 但 既然 讲 到 了 语法 糖 ， 就 来 讲 讲 另 一 个 语 
法 糖 decorator， 正 巧 可 以 用 来 实现 class 上 的 mixin。 

decorator 是 在 ES7 中 定义 的 新 特性 , 与 Java 中 的 pre-defined annotation ( 预定 义 注解 ) 相似 。 
但 与 Java 的 annotation 不 同 的 是 ，decorator 是 运用 在 运行 时 的 方法 。 在 Redux 或 其 他 一 些 应 用 层 
框架 中 ， 越 来 越 多 地 使 用 decorator 以 实现 对 组 件 的 “修饰 ”"。 现 在 ,我 们 使 用 decorator 来 实现 
mixin。 

core-decorators 库 为 开发 者 提供 了 一 些 实用 的 decorator， 其 中 实现 了 我 们 正 想 要 的 emixin。 
下 面 解读 一 下 其 核心 实现 : 






















































































import { getOwnPropertyDescriptors } from './private/utils'; 
const { defineProperty } = Object; 


function handleClass(target, mixins) { 
if (!mixins.Tlength) { 
throw new SyntaxError(“@mixin() class ${target.name} requires at least one mixin as an argument ); 


} 


for (let i = 0, lL = mixins.length; i < l; i++) { 
// 获取 mixins 的 attributes 对 象 
Const descs = getOwnPropertyDescriptors(mixins[i]); 


// 批量 定义 mixins 的 attributes 对 象 

for (const key in descs) { 
if (!(key in target.prototype)) { 

definePproperty(target.prototype, key, descs[key]); 

} 

} 

} 
3 


export default function mixin(...mixins) { 
if (typeof mixins[0] === 'function') { 
return handleClass(mixins[0], []); 
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} elLse { 
return target => { 
return handleClass(target, mixins); 
}; 
} 
} 


可 以 看 到 ， 源 代码 十 分 简单 ， 它 将 每 一 个 mixin 对 象 的 方法 都 琶 加 到 target 对 象 的 原型 上 
以 达到 mixin 的 目的 。 这 样 ， 就 可 以 用 @mixin 来 做 多 个 重用 模块 的 又 加 了 。 比 如 : 








import React, { Component } from 'React'; 
import { mixin } from 'core-decorators'; 


const PureRender = { 
shouldComponentUpdate() {} 
}; 


Const Theme = { 
setTheme() {} 
}; 


@mixin(PureRender , Theme) 

class MyComponent extends Component { 

render() {} 

} 

细心 的 你 应 该 已 经 发 现 了 这 个 mixin 与 createClass 中 的 mixin 的 区 别 。 上 述 实现 中 ，mixin 
的 逻辑 和 最 早 实 现 的 简单 逻辑 很 相似 ， 之 前 直接 给 对 象 的 prototype 属性 赋值 ， 但 这 里 用 了 
getOwnPropertyDescriptor 和 defineproperty 这 两 个 方法 ， 有 什么 区 别 呢 ? 

事实 上 , 这 样 实现 的 好 处 在 于 defineProperty 这 个 方法 , 也 就 是 定义 与 赋值 的 区 别 ， 定义 是 
对 已 有 的 定义 ,赋值 则 是 覆盖 已 有 的 定义 。 所 以 说 前 者 并 不 会 覆盖 已 有 方法 , 但 后 者 会 。 本质 上 
与 官方 的 mixin 方法 都 很 不 一 样 ， 除 了 定义 方法 级 别 不 能 覆盖 之 外 ， 还 得 加 上 对 生命 周期 方法 的 
继承 ， 以 及 对 state 的 合并 。 

再 回 到 decorator 身上 ， 上 述 只 是 作用 在 类 上 的 方法 ， 还 有 作用 在 方法 上 的 ， 它 可 以 控制 方 
法 的 自 有 属性 ， 也 可 以 作 decorator 的 工厂 方法 。 在 其 他 语言 里 ，decorator 用 途 广泛 ， 具 体 扩 展 
不 在 本 书 讨论 的 范围 。 

对 于 React， 我 们 自然 可 以 用 上 述 方法 来 实现 mixin。 但 不 幸 的 是 ， 社 区 从 0.14 版 本 开始 渐 
渐 开 始 剥 离 mixin。 那 么 ， 到 底 是 什么 原因 导致 mixin 成 为 反 模 式 了 呢 ? 


5. mixin 的 问题 


我 们 认可 mixin 给 组 件 开 发 带 来 抽象 的 好 处 ， 但 随 着 大 量 使 用 mixin， 它 的 问题 也 渐渐 暴露 
出 来 了 。Dan Abramov 是 最 早 提出 这 个 问题 的 人 ， 他 总 结 了 mixin 最 大 的 一 些 问题 "。 















































GD Mixins Considered Harmful ， 详 见 https://facebook.github.io/react/blog/2016/07/13/mixins-considered-harmful.html。 
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@ 破坏 了 原 有 组 件 的 封装 

我 们 知道 mixin 方法 会 混入 方法 , 给 原 有 组 件 带 来 新 的 特性 , 比如 mixin 中 有 一 个 renderList 
方法 ， 给 我 们 带 来 了 演 染 List 的 能 力 ， 但 它 也 可 能 带 来 了 新 的 state 和 props， 这 意味 着 组 件 有 一 
些 “ 不 可 见 ” 的 状态 需要 我 们 去 维护 ,但 我 们 在 使 用 的 时 候 并 不 清楚 。 此 外 ，renderList 中 的 方 
法 会 有 调用 组 件 中 的 方法 ,但 很 可 能 被 其 他 mixin 截获 ， 带 来 很 多 不 可 知 。 

男 外 ，mixin 也 有 可 能 去 依赖 其 他 的 mixin， 这 样 会 建立 一 个 mixin 的 依赖 链 ， 当 我 们 改动 其 
中 一 个 mixin 的 状态 时 ， 很 可 能 会 直接 影响 其 他 的 mixin。 解 决 方法 是 可 以 约定 好 输入 和 输出 。 
但 不 幸 的 是 ，mixin 是 平面 结构 ， 所 有 方法 都 在 同一 个 环境 中 ， 我 们 没 法 做 到 很 好 的 约定 。 

@ 命名 冲突 

刚才 也 提 到 了 ，mixin 是 平面 结构 ， 那 么 不 同 mixin 中 的 命名 在 不 可 知 的 情况 ， 重 用 的 情况 
是 不 可 控 的 。 尤 其 是 像 handleChange 这 样 常见 的 名 字 ， 我 们 不 能 在 两 个 mixin 中 同时 使 用 ， 也 不 
能 在 自己 的 组 件 中 使 用 这 个 名 字 的 方法 。 

尽管 我 们 可 以 通过 更 改名 字 来 解决 , 但 遇 到 第 三 方 引 用 , 或 已 经 引用 了 几 个 mixin 的 情况 下 ， 
总 是 要 花 一 定 的 成 本 去 解决 冲突 。 

@ 增加 复杂 性 

在 过 去 写 mixin 的 时 候 , 是 不 是 常 遇 到 这 样 的 情形 : 我 们 设计 一 个 组 件 , 引入 名 为 PopupMixin 
的 mixin ， 这 样 就 给 组 件 引 进 了 PopupMixin 生命 周期 方法 ， 还 有 hidePopup()、startPopup() 等 
方法 。 当 我 们 再 引入 HoverMixin 时 ,将 有 更 多 的 方法 被 引进 ， 比 如 handLeMouseEnter() 、handte- 
MouseLeave()、isHovering() 方 法 。 当 然 ， 我 们 可 以 进一步 抽象 出 TooltipMixin， 将 两 个 整合 在 
一 起 ,但 我 们 发 现 它们 都 有 componentDidUpdate 方法 。 

几 个 月 后 , 再 去 看 组 件 的 实现 时 , 会 发 现代 码 已 经 没 法 维护 , 它 的 逻辑 已 经 复杂 到 难以 理解 。 
写 React 组 件 时 ， 我 们 首先 考虑 的 往往 是 单一 的 功能 、 简 洁 的 设计 和 逻辑 。 当 加 入 功能 的 时 候 ， 
可 以 继续 控制 组 件 的 输入 和 输出 。 如 果 说 因为 复杂 性 ,我 们 不 断 加 入 新 的 状态 , 那么 组 件 肯定 会 
因此 变 得 非常 难以 维护 。 

针对 这 些 困 扰 ，React 社区 提出 了 新 的 方式 来 取代 mixin， 那 就 是 高 阶 组 件 。 




































































































































































2.5.2 ”高 阶 组 件 

higher-order 这 个 单词 相信 各 位 开发 者 都 很 熟悉 ，higher-order function ( 高 阶 函数 ) 在 函数 式 
编程 中 是 一 个 基本 的 概念 ， 它 描述 的 是 这 样 一 种 水 数 : 这 种 函数 接受 孔 数 作为 输入 , 或 是 输出 一 
个 函数 。 比 如 ， 常 用 的 工具 方法 map、reduce 和 sort 等 都 是 高 阶 函 数 。 

高 阶 组 件 ( higher-order component )， 类 似 于 高 阶 函数 ， 它 接受 React 组 件 作 为 输入 ,输出 一 
个 新 的 React 组 件 。 我 们 用 Haskell 的 函数 签名 来 表达 ， 那 就 是 : 
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hocFactory:: W: React.Component => E: React.Component 


用 通俗 的 语言 解释 就 是 ， 当 React 组 件 被 包 庄 时 ( wrapped )， 高 阶 组 件 会 返回 一 个 增强 
(enhanced ) 的 React 组 件 。 可 以 想象 , 高 阶 组 件 让 我 们 的 代码 更 具有 复 用 性 、 逻 辑 性 与 抽象 特性 。 
它 可 以 对 render 方法 作 劫持 ， 也 可 以 控制 props 与 state。 


实现 高 阶 组 件 的 方法 有 如 下 两 种 。 


口 属性 代理 〈props proxy) 。 高 阶 组 件 通过 被 包 庄 的 React 组 件 来 操作 props。 
口 反 向 继承 (inheritance inversion) 。 高 阶 组 件 继承 于 被 包 庄 的 React 组 件 。 


接着 ， 我 们 来 讲述 这 两 种 方法 。 
1. 属性 代理 
属性 代理 是 常见 高 阶 组 件 的 实现 方法 ， 我 们 通过 一 个 例子 来 说 明 : 


import React, { Component } from 'React'; 



































const MyContainer = (WrappedComponent) => 
class extends Component { 
render() { 
return <WrappedComponent {...this.props} />; 
} 
} 


从 这 里 看 到 最 重要 的 部 分 是 render 方法 中 返回 了 传人 WrappedComponent 的 React 组 件 。 这 
我 们 就 可 以 通过 高 阶 组 件 来 传递 props， 这 种 方法 即 为 属性 代理 。 
自然 ， 我 们 想 要 使 用 MyContainer 这 个 高 阶 组 件 就 变 得 非常 容易 : 


import React, { Component } from 'React'; 























其 





class MyComponent extends Component { 
fh ss 
} 


export default MyContainer (MyComponent); 


这 样 组 件 就 可 以 一 层 层 地 作为 参数 被 调用 , 原始 组 件 就 有 具备 了 高 阶 组 件 对 它 的 修饰 。 就 这么 
简单 ， 保 持 单个 组 件 封 装 性 的 同时 还 保留 了 易 用 性 。 当 然 ， 我 们 也 可 以 用 decorator 来 转换 : 


import React, { Component } from 'React'; 








@MyContainer 

class MyComponent extends Component { 
render() 人 0 

} 


export default MyComponent; 
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简单 地 替换 成 作用 在 类 上 的 decorator， 即 接收 需要 装饰 的 类 为 参数 ， 返 回 一 个 新 的 内 部 类 。 
这 与 高 阶 组 件 的 定义 完全 一 致 。 因 此 ， 可 以 认为 作用 在 类 上 的 decorator 语法 糖 简化 了 高 阶 组 件 
的 调用 。 

当 使 用 属性 代理 构建 高 阶 组 件 时 ， 调 用 顺序 不 同 于 mixin。 上 述 执行 生命 周期 的 过 程 类 似 于 
堆栈 调用 

didmount 一 HOC didmount 一 (HOCs didmount) 一 (HOCs will unmount ) 一 HOC will unmount 一 Unmount 


从 功能 上 ， 高 阶 组 件 一 样 可 以 做 到 像 mixin 对 组 件 的 控制 ， 包 括 控制 props、 通 过 refs 使 用 
引用 、 抽 象 state 和 使 用 其 他 元 素 包 衰 WrappedComponent。 


接着 ， 我 们 对 它 的 功能 一 一 进行 解释 。 
@ 控制 props 


我 们 可 以 读 取 、 增 加 、 编 辑 或 是 移 除 从 WrappedComponent 传 进来 的 props， 但 需要 小 心 删 
除 与 编辑 重要 的 props。 我 们 应 该 尽 可 能 对 高 阶 组 件 的 props 作 新 的 命名 以 防止 混淆 。 


例如 ， 我 们 需要 增加 一 个 新 的 prop: 


























import React, { Component } from 'React'; 


const MyContainer = (WrappedComponent) => 
class extends Component { 
render() { 
const newProps = { 
text: newText, 
}; 
return <WrappedComponent {...this.props} {...newProps} />; 
} 
} 


当 调 用 高 阶 组 件 时 ， 可 以 用 text 这 个 新 的 props 了 。 对 于 原 组 件 来 说 ， 只 要 套用 这 个 高 阶 组 
我 们 的 新 组 件 中 就 会 多 一 个 text 的 prop。 


@ 通过 refs 使 用 引用 
在 高 阶 组 件 中 ， 我 们 可 以 接受 refs 使 用 WrappedComponent 的 引用 。 例 如 : 








件 


> 


import React, { Component } from 'React'; 


const MyContainer = (WrappedComponent) => 
class extends Component { 
proc(wrappedComponentInstance) { 
wrappedComponentInstance.method(); 


} 


render() { 
const props = Object.assign({}, this.props, { 
ref: this.proc.bind(this), 
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]); 


return <WrappedComponent {...props} />; 
} 
3 


当 WrappedComponent 被 泻 梁 时，refs 回调 也 数 就 会 被 执行 ， 这 样 就 会 拿 到 一 份 Wrapped- 
Component 实例 的 引用 。 这 就 可 以 方便 地 用 于 读 取 或 增加 实例 的 props， 并 调用 实例 的 方法 。 


@ 抽象 state 


我 们 可 以 通过 WrappedComponent 提供 的 props 和 回调 函数 抽象 state， 这 个 功能 将 在 4.1 市 
中 解释 。 高 阶 组 件 可 以 将 原 组 件 抽象 为 展示 型 组 件 ， 分 离 内 部 状态 。 


下 面 通 过 抽象 一 个 input 组 件 来 举例 : 


























import React, { Component } from 'React'; 


const MyContainer = (WrappedComponent) => 
class extends Component { 
constructor(props) { 
super(props); 
this.state = { 
Name: '"! 


}; 


this.onNameChange = this.onNameChange.bind(this); 


} 


onNameChange(event) { 
this.setState({ 
name: event.target.value, 
}) 
} 


render() { 
Const newProps = { 
name: { 
value: this.state.name, 
onChange: this.onNameChange， 
}, 
} 
return <WrappedComponent {...this.props} {...newProps} />; 
} 
} 


在 这 个 例子 中 ， 我 们 把 input 组 件 中 对 name prop 的 onChange 方法 提取 到 高 阶 组 件 中 ， 这 样 
就 有 效 地 抽象 了 同样 的 state 操作 。 可 以 这 么 来 使 用 它 : 


import React, { Component } from 'React'; 

















@MyContainer 
class MyComponent extends Component { 
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render() { 
return <input name="name" {...this.props.name} />; 


} 
} 


通过 这 样 的 封装 ， 我 们 就 得 到 了 一 个 被 控制 的 input 组 件 。 

@ 使 用 其 他 元 素 包 庄 WrappedComponent 

此 外 ， 我 们 还 可 以 使 用 其 他 元 素来 包 于 WrappedComponent， 这 既 可 以 是 为 了 加 样式 ， 也 可 
以 是 为 了 布局 。 比 如 ， 我 们 增加 一 层 来 定义 样式 : 




















import React, { Component } from 'React'; 


const MyContainer = (WrappedComponent) => 
class extends Component { 
render() { 
return ( 
<div style={{display: 'block'}}> 
<WrappedComponent {...this.props} /> 
</div> 
) 
} 
} 


下 面 我 们 再 来 讨论 一 下 高 阶 组 件 与 mixin 的 不 同 之 处 ， 如 图 2-1 所 示 。 


组 件 





mixin HOC 


图 2-1 mixin 与 高 阶 组件 的 区 别 





2-1 其 实 已 经 很 清晰 地 表达 了 mixin 与 高 阶 组 件 的 不 同 之 处 。 简 单 来 说 ， 高 阶 组 件 符合 函 
数 式 编程 思想 。 对 于 原 组 件 来 说 ,并 不 会 感知 到 高 阶 组 件 的 存在 ,只 需要 把 功能 套 在 它 之 上 就 可 
以 了 ， 从 而 避免 了 使 用 mixin 时 产生 的 副作用 。 

2. 反 向 继承 

男 一 种 构建 高 阶 组 件 的 方法 称 为 反 向 继承 ,从 字面 意思 上 看 , 它 一 定 与 继承 特性 相关 。 我 们 
同样 来 看 一 个 简单 的 实现 : 
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const MyContainer = (NrappedComponent) => 
CLass extends WrappedComponent { 
render() { 
return super.render(); 
4 
} 


正如 所 见 ， 高 阶 组 件 返 回 的 组 件 继 承 于 WrappedComponent。 因 为 被 动 地 继承 了 WrappedCom- 
ponent， 所 有 的 调用 都 会 反 向 ， 这 也 是 这 种 方法 的 由 来 。 

这 种 方法 与 属性 代理 不 太一 样 。 它 通过 继承 WrappedComponent 来 实现 , 方法 可 以 通过 super 
来 顺序 调用 。 因 为 依赖 于 继承 的 机 制 ，HOC 的 调用 顺序 和 队列 是 一 样 的 : 


didmount 一 HOC didmount 一 (HOCs didmount)—will unmount 一 HOC will unmount— (HOCs will unmount) 


在 反 向 继承 方法 中 ， 高 阶 组 件 可 以 使 用 WrappedComponent 引用 ， 这 意味 着 它 可 以 使 用 
WrappedComponent 的 state 、props 、 生 命 周 期 和 render 方 法 。 但 它 不 能 保证 完整 的 子 组 件 树 被 解析 。 

它 有 两 个 比较 大 的 特点 ， 下 面 我 们 展开 来 讲 一 讲 。 

@ 泻 染 劫持 

泻 染 支持 指 的 就 是 高 阶 组 件 可 以 控制 WrappedComponent 的 泻 染 过 程 ， 并 泻 染 各 种 各 样 的 结 
果 。 我 们 可 以 在 这 个 过 程 中 在 任何 React 元 素 输出 的 结果 中 读 取 、 增 加 、 人 修改、 删除 props， 或 
读 取 或 修改 React 元 素 树 ， 或 条 件 显示 元 素 树 ， 又 或 是 用 样式 控制 包 豪 元 素 树 。 

正如 之 前 说 到 的 , 反 向 继承 不 能 保证 完整 的 子 组 件 树 被 解析 , 这 意味 着 将 限制 泻 染 劫持 功能 。 
演 染 支持 的 经 验 法 则 是 我 们 可 以 操控 WrappedComponent 的 元 素 树 ， 并 输出 正确 的 结果 。 但 如 果 
元 素 树 中 包括 了 荫 数 类 型 的 React 组 件 ， 就 不 能 操作 组 件 的 子 组 件 。 


我 们 先 来 看 条 件 演 染 的 示例 : 


const MyContainer = (WrappedComponent) => 
class extends WrappedComponent { 
render() { 
if (this.props.LoggedIn) { 
return super.render(); 
} else 
return null; 
} 
} 
} 


第 二 个 示例 是 我 们 可 以 对 render 的 输出 结果 进行 修改 : 













































































const MyContainer = (WrappedComponent) =>; 
class extends WrappedComponent { 
render() { 
const elementsTree = super.render(); 
let newProps = {}; 
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if (elementsTree && elementsTree.type === 'input') { 
newProps = {value: 'may the force be with you'}; 


小 
Const props = Object.assign({}, elementsTree.props, newProps); 


const newELementsTree = React.cloneElement(elementsTree, props, elementsTree.props.children); 
return newELementsTree; 
} 


} 


在 这 个 例子 中 ，WrappedComponent 的 演 染 结果 中 ， 顶 层 的 input 组 件 的 value 被 改写 为 may 


the force be with you。 因 此 ， 我 们 可 以 做 各 种 各 样 的 事 ， 甚 至 可 以 反 转 元 素 树 ， 或 是 改变 元 素 
树 中 的 props。 这 也 是 Radium 库 构 造 的 方法 。 


@ 控制 state 


























高 阶 组 件 可 以 读 取 、 修 改 或 删除 WrappedComponent 实例 中 的 state， 如 果 需 要 的 话 ， 也 可 以 
增加 state。 但 这 样 做 ， 可 能 会 让 WrappedComponent 组 件 内 部 状态 变 得 一 团 糟 。 大 部 分 的 高 阶 组 


总 之 


件 都 应 该 限制 读 取 或 增加 state， 尤 其 是 后 者 ， 可 以 通过 重新 命名 state， 以 防止 混淆 。 
我 们 来 看 一 个 例子 : 





























const MyContainer = (WrappedComponent) => 
class extends WrappedComponent { 
render() { 
return ( 
<div> 
<h2>HOC Debugger Component</h2> 
<p>Props</p> <pre>{JSON.stringify(this.props, null, 2)}</pre> 
<p>State</p><pre>{JSON.stringify(this.state, null, 2)}</pre> 
{super.render()} 
</div> 
); 
小 
} 








在 这 个 例子 中 , 显示 了 WrappedComponent 的 props 和 state, 以 方便 我 们 在 程序 中 去 调试 它们 。 
3. 组 件 命名 


当 包 豪 一 个 高 阶 组 件 时 ， 我 们 失去 了 原始 WrappedComponent 的 displayName ， 而 组 件 名 字 
是 方便 我 们 开发 与 调试 的 重要 属性 。 


那 可 以 怎么 做 呢 ? 这 里 可 以 参考 react-redux 库 中 的 实现 : 














HOC.dispLayName = “HOC(S{fgetDispLayName(NWrappedComponent)}) ; 
// 或 者 


CLass HOC extends ... { 
static displayName = “HOC(S{fgetDispLayName(NrappedComponent)}) ; 
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} 
getDisplayName 方法 可 以 这 样 来 实现 : 


function getDisplayName(WrappedComponent) { 
return WrappedComponent.displayName || 
WrappedComponent.name || 
'Component'; 





} 
或 可 以 使 用 recompose 库 ， 它 已 经 帮 我 们 实现 了 相应 的 方法 。 
4. 组 件 参 数 


有 了 时， 我 们 调用 高 阶 组 件 时 需要 传 和 一些 参 数 ， 这 可 以 用 非常 简单 的 方式 来 实现 : 
import React, { Component } from 'React'; 


function HOCFactoryFactory(...params) { 
// 可 以 做 一 些 改 变 params 的 事 
return function HOCFactory(WrappedComponent) { 
return class HOC extends Component { 
render() { 
return <WrappedComponent {...this.props} />; 
} 
} 
} 
} 


当 你 使 用 的 时 候 ， 可 以 这 么 写 : 
HOCFactoryFactory(params)(WrappedComponent) 
// 或 者 


@HOCFatoryFactory(params) 
class WrappedComponent extends React.Component{} 


这 也 是 利用 了 函数 式 编程 的 特性 。 可 见 ， 在 React 抽象 的 过 程 中 ， 处 处 可 见 它 的 影子 。 


























2.5.3 组 合式 组 件 开发 实践 


之 前 我 们 多 次 提 到 ， 使 用 React 开发 组 件 时 利用 props 传递 参数 。 也 就 是 说 ， 用 参数 来 配置 
组 件 是 我 们 最 常用 的 封装 方式 。 在 一 般 场 景 中 , 仅 修改 组 件 用 于 配置 的 props， 就 可 以 满足 需求 。 
但 随 着 场景 发 生变 化 ， 组 件 的 形态 也 发 生变 化 时 ， 我 们 就 必须 不 断 增加 props 去 应 对 变化 ， 此 时 
便 会 导致 props 的 泛滥 ， 而 在 扩展 过 程 中 又 必须 保证 组 件 向 下 兼容 ， 只 增 不 减 ， 使 组 件 的 可 维护 
性 降低 。 

因此 ,我们 就 可 以 利用 上 述 高 阶 组 件 的 思想 ， 提 出 组 件 组 合式 开发 模式 ， 有 效 地 解决 了 配置 
式 所 存在 的 一 些 问题 。 
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1. 组 件 再 分 离 

当然 ,我 们 期望 组 件 是 没有 宛 余 的 , 组 件 与 组 件 间 视 图 重 释 的 部 分 应 当 被 抽 离 出 来 ,形成 颗 
粒度 更 细小 的 原子 组 件 , 使 组 件 组 合 充 满 更 多 的 可 能 。 先 来 看 一 下 比较 典型 的 3 个 公共 组 件 ， 如 
图 2-2 所 示 。 








Select Search SearchSelect 


Searchlnput 





Selectlnput 


图 2-2 3 个 公共 组 件 

这 3 个 组 件 无 论 从 UI 还 是 逻辑 上 均 存 在 一 定 的 共性 。 在 配置 方式 中 ， 我 们 会 将 这 3 个 组 件 
通过 一 个 组 件 的 配置 变换 来 实现 ,但 这 么 做 无 疑 会 提高 单个 组 件 内 部 逻辑 的 复杂 性 。 

我 们 来 做 一 次 分 离 , 它们 可 由 SelectInput、SearchInput 与 List 三 个 颗粒 度 更 细 的 组 件 来 组 合 。 
对 于 颗粒 度 最 小 的 组 件 而 言 ， 我 们 和 希望 它 是 纯粹 的 、 木 偶 式 的 组 件 。 

例如 ， 对 于 SelectInput 组 件 ， 其 状态 完全 依赖 传人 的 props， 包 括 selectedItem ( 显示 用 户 
所 选项 )、isActive ( 当前 下 拉 状 态 )、onClickHeader (反馈 下 拉 状 态 ) 以 及 placeholder ( 下拉 
框 提示 )。 我 们 来 看 一 下 它 的 简要 实现 : 


class SelectInput extends Component { 
static displayName = 'SelectInput'; 





























render() { 
const { selectedItem, isActive, onClickHeader, placeholder } = this.props; 
const { text } = seLectedItem; 


return ( 
<div> 
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<div onClick={onClickHeader}> 
<Input 
type="text" 
disabled 
value={text} 
placeholder={placeholder} 
/> 
<Icon className={isActive} name="angle-down" /> 
</div> 
</div> 
); 
} 
站 


组 件 再 次 分 离 后 , 我 们 就 可 以 根据 在 现实 中 的 组 件 形态 对 其 进行 任意 组 合 , 形成 统一 层 , 摆 
脱 在 原 有 组 件 上 扩展 的 模式 ， 有 效 提高 组 件 的 灵活 性 。 


2. 逻辑 再 抽象 


组 件 层面 的 抽象 不 仅仅 只 停留 在 界面 上 ， 组 件 中 的 相同 交互 逻辑 和 业务 逻辑 也 应 该 进行 抽 
象 。 在 组 件 中 ,同样 贯穿 着 这 种 函数 式 思想 ， 只 是 实现 方式 略 有 不 同 。 现 在 基于 高 阶 组 件 来 完成 
组 件 逻 辑 上 的 抽象 : 


// 完成 SearchInput 与 List 的 交互 
const searchDecorator = WrappedComponent => { 
class SearchDecorator extends Component { 
constructor(props) { 
super(props); 




















this.handleSearch = this.handleSearch.bind(this); 
} 


handleSearch(keyword) { 
this.setState({ 
data: this.props.data, 
keyword ， 
]); 
this.props.onSearch(keyword); 


} 


render() { 
Const { data, keyword } = this.state; 
return ( 
<WrappedComponent 
{...this.props} 
data={data} 
keyword={keyword} 
onSearch={this.handleSearch} 
/> 
); 
} 
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return SearchDecorator ; 


} 


// 完成 List 数据 请 求 
const asyncSelectDecorator = WrappedComponent => { 
class AsyncSelectDecorator extends Component { 
componentDidMount() { 
const { url, params } = this.props; 


fetch(url, { params }).then(data => { 
this.setState({ 
data, 
}); 


render() { 
return ( 
<WrappedComponent 
{...this.props} 
data={this. state.data} 
/> 


return AsyncSelectDecorator; 


} 


最 终 , 我 们 既 可 以 用 decorator 的 方式 至 加 套用 ,也 可 以 利用 compose 方法 将 高 阶 组 件 层 层 包 
庄 ， 将 界面 与 逻辑 完美 地 结合 在 一 起 : 





const FinalSelector = compose(asyncSelectDecorator, searchDecorator, 
seLectedItemDecorator )(SeLector ); 


class SearchSelect extends Component { 
render() { 
return ( 
<FinalSelector {...this.props}> 
<SelectInput /> 
<SearchInput /> 
<List /> 
</FinalSelector> 
); 
} 
3} 


在 配置 式 组 件 内 部 , 组 件 与 组 件 间 以 及 组 件 与 业务 间 是 紧密 关联 的 , 而 我 们 需要 完成 的 仅仅 
是 配置 工作 。 如 图 2-3 所 示 ， 组 合式 的 方式 意图 打破 这 种 关联 ， 和 寻求 单元 化 ， 通 过 颗粒 度 更 细 的 


基础 组 件 与 抽象 组 件 共有 交互 与 业务 逻辑 的 高 阶 组 件 ,， 使 组 件 更 灵活 , 更易 扩展 ,也 使 我 们 能 够 
完成 对 于 基础 组 件 的 自由 支配 。 
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基础 组 件 





基础 组 件 





基础 组 件 





基础 组 件 





图 2-3 组 合式 组 件 架 构 





从 侵入 组 件 到 与 组 件 解 看 ，React 一 直 推 崇 的 声明 式 编程 都 优 于 命令 式 编程 ， 正 如 mixin 到 
高 阶 组 件 的 发 展 。 对 于 “重用 ”， 从 语言 层面 上 来 讲 ， 都 是 为 了 可 以 更 好 地 实现 抽象 ， 而 实现 的 
灵活 性 与 写法 之 间 也 存在 着 一 个 微妙 的 平衡 。 



































2.6 组 件 性 能 优化 


从 过 往 的 经 验 与 实践 中 ， 我 们 都 知道 影响 网 页 性 能 最 大 的 因素 是 浏览 器 的 重 绘 (reflow ) 和 
重 排版 (repaint )。React 背后 的 Virtual DOM 就 是 尽 可 能 地 减少 浏览 器 的 重 绘 与 重 排版 。 

对 于 性 能 优化 这 个 主题 ， 我 们 往往 会 基于 “不 信任 ”的 前 提 ， 即 我 们 需要 提高 React Virtual 
DOM 的 效率 。 从 React 的 演 染 过 程 来 看 ， 如 何 防 止 不 避 要 的 演 染 可 能 是 最 需要 去 解决 的 问题 。 
然而 ， 针 对 这 个 问题 ，React 官方 提供 了 一 个 便捷 的 方法 来 解决 ， 那 就 是 PureRender。 


















































2.6.1 纯 函 数 


要 理解 PureRender 中 的 Pure， 还 要 从 函数 式 编 程 的 基本 概念 “ 纯 函 数 ” 讲 起 。 纯 函数 由 三 
大 原则 构成 : 
口 给 定 相同 的 输入 ， 它 总 是 返回 相同 的 输出 ; 
口 过 程 没 有 副作用 ( side effect ) ”; 
口 没有 额外 的 状态 依赖 。 

我 们 都 喜欢 这 样 的 方法 。 记 得 在 计算 机 科学 中 有 这 样 一 条 设计 原则 KISS (Keep It Simple， 
Stupid )， 而 纯 函 数 正 是 在 简洁 性 与 傻瓜 化 方面 做 到 了 极致 。 

纯 函 数 也 是 函数 式 编程 的 基础 , 它 完 全 独立 于 外 部 状态 , 这 样 就 避免 了 因为 共享 外 部 状态 而 
导致 的 bug。 这 种 独立 ， 让 我 们 可 以 利用 CPU 在 分 布 式 集群 上 作 并 行 计 算 ， 这 对 于 多 种 科学 计 



























































QD side effect (computer science)， 详 见 https:Wen.wikipedia.org/wiki/Side_effect (computer science)。 
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算 和 资源 密集 型 计算 任务 是 非常 核心 的 一 点 ， 让 计算 机 高 效 地 处 理 这 类 任务 变 得 可 能 。 
此 外 , 纯 函 数 非 常 方 便 进行 方法 级 别 的 测试 以 及 重 构 ,可 以 让 程序 具有 良好 的 扩展 性 及 适应 性 。 
我 们 再 来 看 看 纯 函 数 的 第 一 个 条 件 “ 给 定 相 同 的 输入 ， 它 总 是 返回 相同 的 输出 ”， 这 是 什么 
假如 我 们 定义 一 个 “定义 加 法 ”的 方法 f， 然 后 改变 它 的 输入 为 f(2，5)， 那 么 不 管 方法 的 
上 下 文 ， 不 论 什 么 时 间 调 用 或 多 少 次 的 调用 ， 它 总 是 返回 7。 用 数学 语言 表达 即 为 f(x,y)=z， 当 
给 定 变 量 x 和 y， 作 用 在 上 ， 结 果 始 终 为 z。 
但 并 不 是 所 有 方法 都 适应 这 个 条 件 ,有 些 方法 的 结果 并 不 完全 依赖 于 你 所 传 入 的 参数 ,比如 ， 
Math.random(); // => 0.8982946265648812 


Math.random(); // => 0.5326573647965065 
Math.random(); // => 0.08841438748355146 


就 算 我 们 不 传 任何 参数 到 方法 中 ， 该 方法 也 依然 总 是 会 输出 不 同 的 结果 。 从 这 个 意义 上 说 ， 
Math.random() 就 不 满足 纯 函 数 的 条 件 。 还 有 下 面 的 例子 : 


function time() { return new Date().toLocaleTimeString(); } 

看 到 time 一 定 习 然 大 悟 了 吧 。 获 取 时 间 的 方法 也 是 同样 的 ， 不 论 我 们 限定 更 新 时 间 的 区 间 
在 秒 、 分 、 时 ， 甚 至 是 年 ， 它 总 是 会 在 这 个 范围 之 外 改变 值 而 导致 不 能 做 到 输入 和 输出 一 致 。 

还 有 我 们 常用 的 stlice 和 sptLice 方法 ， 它 们 有 相似 的 功能 ， 都 可 以 用 来 作 数 据 截 取 。 那 么 ， 
它们 的 执行 结果 是 一 致 的 么 ”比如 : 














































































































const stars = ['Earth', 'Mars', 'Mercury', 'Venuyus']; 


stars.slice(0, 2); // => ['Earth', 'Mars'] 
stars.slice(0, 2); // => ['Earth', 'Mars'] 
stars.slice(0, 2); // => ['Earth', 'Mars'] 


stars.splice(0, 2) // => ['Earth', 'Mars'] 

stars.splice(0, 2) // => ['Mercury', 'Venus'] 

stars.splice(0, 2) // => [] 

我 们 清晰 地 看 到 slice 方法 在 参数 一 定 的 情况 下 输出 是 完全 一 样 的 ， 而 splice 方法 的 执行 
结果 会 改变 原 数 组 。 对 于 程序 来 说 ，splice 的 隐藏 行为 是 危险 的 ， 因 为 这 是 常会 令 仆 外 的 隐 式 
改变 。 在 Ruby 语言 的 设计 中 ,会 用 ! 号 来 区 分 是 否 改变 原始 值 ， 这 是 一 个 很 好 的 提醒 。 

当然 , 还 有 很 多 情况 是 在 不 同 的 输入 下 会 有 相同 的 输出 , 但 从 概念 上 说 ,这 个 方法 也 还 是 纯 
函数 。 例 如 : 
























































function compare(val, comparedVal) { return val <= comparedVal; } 


compare(1, 3); // => true 
compare(1, 5); // => true 
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compare(1, 7); // => true 


compare(7, 1); // => false 

compare(9, 1); // => false 

compare(11, 1); // => false 

第 二 个 条 件 “ 过 程 没 有 副作用 ”， 其 实 很 好 理解 ， 就 是 说 在 纯 函 数 中 我 们 不 能 改变 外 部 状态 。 

而 在 JavaScript 中 改变 外 部 状态 的 情况 比比 丝 是 ， 就 比如 方法 的 参数 是 对 象 或 数组 ， 那 么 它 本 身 i 
就 有 可 能 被 方法 执行 的 过 程 改变 。 例 如 ， 


const addToCart = (cart, item, quantity) => { 
cart.items.push({ 
item, 
quantity, 
]); 
return cart; 


}; 
当 我 们 调用 方法 的 时 候 ， 


const originalCart = { 
items: []， 


}; 























const cart = addToCart( 
originalCart, 


{ 


name: "Digital SLR Camera", 
price: '1495', 


}, 
1 


); 

这 个 例子 很 简单 。 这 是 一 个 加 入 到 “购物 车 ”的 方法 ， 但 在 执行 addTocart 方法 的 时 候 ， 改 
变 了 originatLCart 对 象 。 尽 管 我 们 返回 了 新 对 象 ， 但 因为 在 JavaScript 中 对 象 是 引用 ， 因 此 原来 
的 对 象 也 改变 了 。 这 就 产生 了 副作用 。 

此 ， 我 们 提出 了 Immutable 的 概念 ， 让 参数 中 的 引用 重新 复制 。 这 里 我 们 借用 了 lodash 的 
cloneDeep 方法 来 作 深 挝 贝 ; 


import '_' from "Lodash ' ; 





(cart, item, quantity) => { 
_.CloneDeep(cart); 


const addToCart = 
const newCart = 

newCart.items.push({ 
item, 
quantity, 

}); 


return newCart; 


}; 
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这 样 ， 我 们 就 不 会 担心 方法 影响 了 外 部 参数 。 这 也 告诉 了 我 们 Immutable 是 多 么 重要 。 在 本 
节 后 续 部 分 ,我们 会 重点 讲述 这 一 概念 及 其 运用 。 

第 三 个 条 件 “ 没 有 额外 的 状态 依赖 "*， 就 是 指 方法 内 的 状态 都 只 在 方法 的 生命 周期 内 存活 ， 
这 意味 着 我 们 不 能 在 方法 内 使 用 共享 变量 ， 因 为 这 会 给 方法 带 来 不 可 知 因素 。 

React 在 设计 时 带 有 函数 式 编程 的 基因 ， 因 为 React 组 件 本 喘 就 是 纯 图 数 。React 的 
createElement 方法 保证 了 组 件 是 纯净 的 ， 即 传人 指定 props 得 到 一 定 的 Virtual DOM， 整 个 过 程 
都 是 可 预测 的 。 

我 们 可 以 通过 拆 分 组 件 为 子 组 件 , 进而 对 组 件 做 更 细 粒 度 的 控制 。 这 也 是 函数 式 编程 的 魅力 
之 一 ， 保 持 纯净 状态 ， 可 以 让 方法 或 组 件 更 加 专注 (focused )， 体 积 更 小 ( small )， 更 独立 
(independent )， 更 具有 复 用 性 (reusability ) 和 可 测试 性 ( testability )。 















































2.6.2 PureRender 


PureRender 是 React 组 件 开发 中 一 个 重要 的 概念 。 上 一 节 我 们 详解 了 纯 函 数 ，PureRender 中 
的 Pure 指 的 就 是 组 件 满足 纯 函 数 的 条 件 ， 即 组 件 的 泻 染 是 被 相同 的 props 和 state 演 染 进而 得 到 
相同 的 结果 。 这 个 概念 与 上 述 给 定 相 同 的 输入 ， 它 总 是 返回 相同 的 输出 一 致 。 
1. PureRender 本 质 


怎么 实现 PureRender 的 过 程 呢 ? 官方 在 早期 就 为 开发 者 提供 了 名 为 react-addons-pure-render- 
mixin 的 插件 。 其 原理 为 重新 实现 了 shouldComponentUpdate 生命 周期 方法 ， 让 当前 传人 的 props 
和 state 与 之 前 的 作 浅 比较 ， 如 果 返 回 false， 那 么 组 件 就 不 会 执行 render 方法 。 


这 里 讲 到 了 用 shouLdComponentUpdate 来 作 性 能 优化 的 方法 。 在 理想 情况 下 , 不 考虑 props 和 
state 的 类 型 ， 那 么 要 作 到 充分 比较 ， 只 能 通过 深 比 较 ， 但 是 它 实在 是 太 昂贵 了 : 
shouldComponentUpdate(nextProps, nextState) { 
// 太史 贵 了 
return isDeepEqual(this.props, nextProps) && 


isDeepEqual(this.state, nextState); 
} 


然而 ，PureRender 对 object 只 作 了 引用 比较 ， 并 没有 作 值 比较 。 对 于 实现 来 说 ， 这 是 一 个 取 
舍 问 题 。PureRender 源 代码 中 只 对 新 旧 props 作 了 浅 比较 。 以 下 是 shaLLowEquat 的 示例 代码 : 















































function shallowEqual(obj, newObj) { 
if (obj === newO0bj) { 
return true; 


} 


Const objKeys = Object.keys(obj); 
const newObjKeys = Object.keys(new0bj); 
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if (objKeys.length !== newObjKeys.length) { 
return false; 


} 


// 关键 代码 ， 只 需 关 注 props 中 每 一 个 是 否 相等 ， 无 需 深 入 判断 
return objKeys.every(key => { 
return newObj[key] === obj[key]; 
}); 
} 


2. 运用 PureRender 


利用 createclass 构建 组 件 时 , 可 以 使 用 官方 的 插件 , 其 名 为 react-addons-pure-render-mixin。 
此 外 ， 用 ES6 classes 语法 一 样 可 以 使 用 这 个 插件 ， 比 如 : 


import React, { Component } from 'react'; 
import PureRenderMixin from 'react-addons-pure-render-mixin'; 





class App extends Component { 
constructor(props) { 
super(props); 


this.shouldComponentUpdate = PureRenderMixin.shouldComponentUpdate.bind(this); 
} 


render() { 
return <div className={this.props.className}>foo</div>; 
} 
} 


当然 ， 我 们 也 可 以 用 前 面 介绍 的 decorator 来 实现 ， 其 中 pure-render-decorator 库 已 经 帮 有 我们 
实现 了 所 需要 的 功能 。 在 组 件 化 开发 过 程 中 , 要 尽 可 能 地 满足 Pure, 这 样 才能 保证 对 相应 的 变更 
作出 最 少 的 泻 染 。 

3. 优化 PureRender 

在 使 用 React 写 组 件 的 过 程 中 ，PureRender 可 能 是 最 重要 也 是 最 常见 的 性 能 优化 方法 。 试 想 
在 数据 可 变 的 情况 下 , 深 比 较 的 成 本 是 相当 昂贵 的 。 但 事实 上 , 浅 比 较 可 以 覆盖 的 场景 并 不 是 那么 
多 。 如 果 说 props 或 state 中 有 以 下 几 种 类 型 的 情况 , 那么 无 论 如 何 , 它 都 会 触发 PureRender 为 true。 

@ 直接 为 props 设置 对 象 或 数组 

我 们 知道 ， 每 次 调用 React 组 件 其 实 都 会 重新 创建 组 件 。 就 算 传人 的 数组 或 对 象 的 值 没 有 改 
变 ， 它 们 引用 的 地 址 也 会 发 生 改 变 。 比 如 ， 下 面 为 Account 组 件 设置 一 个 style prop : 

<Account style={{ color: 'black' }} /> 

这 样 设置 prop， 则 每 次 演 染 时 style 都 是 新 对 象 。 对 于 这 样 的 赋值 操作 ， 我 们 只 需要 提前 赋 
值 成 常量 ,不 直接 使 用 字面 量 即 可 。 再 比如 ， 我 们 为 style prop 设置 一 个 默认 值 也 是 一 样 的 道理 : 


<Account style={this.props.style || {}} /> 
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此 时 ， 我 们 只 需要 将 默认 值 保 存 成 同一 份 引用 ， 就 可 以 避免 这 个 问题 : 


Const defaultStyle = {}; 
<Account style={this.props.style || defaultStyle} /> 


同样 ， 像 在 props 中 为 对 象 或 数据 计算 新 值 会 使 PureRender 无 效 : 
<Item items={this.props.items.filter(item => item.val > 30)} /> 


我 们 可 以 马上 想到 始终 让 对 象 或 数组 保持 在 内 存 中 就 可 以 增加 命中 率 。 但 保持 对 象 引用 不 符 
合 函 数 式 编程 的 原则 ， 这 为 函数 带 来 了 副作用 ， 下 一 节 介 绍 的 Inmutablejs 可 以 优雅 地 解决 这 类 





@ 设置 props 方法 并 通过 事件 绑 定 在 元 素 上 
这 与 2.1.2 节 讲 述 的 是 同一 件 事 ， 只 是 从 优化 的 角度 重新 提起 。 比 如 : 


import React, { Component } from 'react'; 


























class MyInput extends Component { 
constructor(props){ 
super (props); 


this.handleChange = this.handleChange.bind(this); 
} 


handleChange(e) { 
this.props.update(e.target.value); 
} 


render() { 
return <input onChange={this.handleChange} />; 
} 
} 


我 们 不 用 每 次 都 绑 定 事件 ,因此 把 绑 定 移 到 构造 器 内 。 如 果 绑 定 方法 需要 传递 参数 , 那么 可 
以 考虑 通过 抽象 子 组 件 或 改变 现 有 数据 结构 解决 。 
@ 设置 子 组 件 


对 于 设置 了 子 组 件 的 React 组 件 , 在 调用 shouLdComponentUpdate 时 , 均 返 回 true。 为 什么 呢 ? 
下 面 以 NameItem 组 件 为 例 来 介绍 : 








import React, { Component } from 'react'; 


Class NameItem extends Component { 
render() { 
return ( 
<Item> 
<span>Arcthur</span> 
<Item/> 
) 
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} 
: 
上 面 的 子 组 件 JSX 部 分 翻译 过 来 ， 其 实 是 : 
<Item 
children={React.createElement('span', {}, 'Arcthur')} 
/> 
显然 ，Item 组 件 不 论 什么 情况 下 都 会 重新 泻 染 。 那 么 ， 怎 么 避免 Item 组 件 的 重复 演 染 呢 ? 

















很 简单 ， 我 们 给 NamelItem 设置 PureRender， 也 就 是 说 提 到 父 级 来 判断 : 


import React, { Component } from 'react'; 
import PureRenderMixin from 'react-addons-pure-render-mixin'; 


class NameItem extends Component { 
constructor(props) { 
super(props); 


this.shouldComponentUpdate = PureRenderMixin.shouldComponentUpdate.bind(this); 
} 


render() { 
return ( 
<Item> 
<span>Arcthur</span> 
</Item> 
); 
} 
} 


如 果 Nameltem 再 加 兄弟 组 件 ，Item 组 件 不 得 不 被 影响 到 ， 解 决 方法 同样 是 将 Item 抽象 的 


Nameltem 提出 。 





2.6.3 Immutable 


在 传递 数据 时 ， 可 以 直接 使 用 Immutable Data 来 进一步 提升 组 件 的 泻 染 性 能 。 


JavaScript 中 的 对 象 一 般 是 可 变 的 (mutable ), 因为 使 用 了 引用 赋值 , 新 的 对 象 简单 地 引用 了 
原始 对 象 ， 改 变 新 的 对 象 将 影响 到 原始 对 象 。 比 如 : 


foo = {a:1}; 


bar = foo; 
bar.a = 2; 
我 们 给 bar .a 赋值 后 ， 会 发 现 此 时 foo.a 也 改 成 了 2。 虽然 这 样 做 可 以 节约 内 存 ， 但 当 应 用 





复杂 后 ,这 就 造成 了 非常 大 的 隐患 ， 可 变性 之 来 的 优点 变 得 得 不 偿 失 。 为 了 解决 这 个 问题 ,一 般 
的 做 法 是 使 用 浅 拷贝 ( shallowCopy ) 或 深 拷贝 ( deepCopy ) 来 避免 被 修改 , 但 这 样 做 又 造成 了 CPU 
和 内 存 的 浪费 。 
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这 时 Immutable 的 出 现 很 好 地 解决 这 些 问题 。 
1. Immutable Data 


Immutable Data 就 是 一 旦 创建 ， 就 不 能 再 更 改 的 数据 。 对 Immutable 对 象 进行 修改 、 添 加 或 
删除 操作 ， 都 会 返回 一 个 新 的 Inmutable 对 象 。Immutable 实现 的 原理 是 持久 化 的 数据 结构 
( persistent data structure )， 也 就 是 使 用 旧 数 据 创 建新 数据 时 ， 要 保证 旧 数 据 同时 可 用 且 不 变 。 同 
时 为 了 避免 深 拷 贝 把 所 有 节点 都 复制 一 遍 带 来 的 性 能 损耗 , Immutable 使 用 了 结构 共享 ( structural 
sharing )， 即 如 果 对 象 树 中 一 个 节点 发 后 变化， 只 修改 这 个 节点 和 受 它 影响 的 父 节 点 ， 其 他 节点 
则 进行 共享 。 

Facebook 工程 师 Lee Byron 花费 三 年 时 间 打 造 Immutable.js 库 ， 与 React 同期 出 现 ， 但 没有 
被 默认 放 到 React 工具 集 里 〈React 提供 了 简化 的 Helper )。 它 内 部 实现 了 一 套 完 整 的 持久 化 数据 
结构 ， 还 有 很 多 易 用 的 数据 类 型 ， 比 如 collection、List、Map、Set、Record、Seq。 有 非常 全 面 
的 map、filter 、groupBy、reduce、find 等 图 数 式 操 作 方 法 。 同 时 ,API 也 尽量 与 JavaScript 的 0bject 
或 Array 类 似 。 

其 中 有 3 种 最 重要 的 数据 结构 说 明 一 下 。 

口 Map: 键 值 对 集合 ， 对 应 于 0bject，ES6 也 有 专门 的 Map 对 象 。 
口 List: 有 序 可 重复 的 列表 ， 对 应 于 Array。 
口 ArraySet : 无 序 且 不 可 重复 的 列表 。 
2. Immutable 的 优点 
Immutable 的 优点 有 如 下 几 点 。 
口 降低 了 “可 变 ” 带 来 的 复杂 度 。 可 变数 据 耦 合 了 time 和 value 的 概念 ， 造 成 了 数据 很 难 
被 回 湖 。 比 如 : 
function touchAndLog(touchFn) { 
let data = { key: 'value' }; 
touchFn(data); 


console.log(data.key); 
} 


在 不 查看 touchFn 的 代码 的 情况 下 ， 因 为 不 确定 方法 对 data 做 了 什么 ,我们 是 不 可 能 知 
道 结果 是 什么 。 但 如 果 data 是 不 可 变 的 呢 ， 你 会 很 肯定 地 知道 打印 的 结果 是 value。 


口 节省 内 存 。Immutable 使 用 结构 共享 尽量 复 用 内 存 。 没 有 被 引用 的 对 象 会 被 垃圾 回收 : 






































































































































import { Map } from 'immutable'; 


let a = Map({ 

select: 'users', 

filter: Map({ name: 'Cam' }), 
]); 
Let b = a.set('select', 'people'); 
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a === b; // => false 
a.get('filter') === b.get('filter'); // => true 
上 面 a 和 b 共享 了 没有 变化 的 filter 节点 。 
口 撤销 / 重 做 ， 复 制 /粘贴 ， 甚 至 时 间 旅 行 这 些 功能 做 起 来 都 是 小 菜 一 碟 。 因 为 每 次 数据 都 是 
不 一 样 的 ， 那 么 只 要 把 这 些 数据 放 到 一 个 数组 里 存储 起 来 ， 想 回 退 到 哪里 ， 就 拿 出 对 应 
的 数据 ， 这 很 容易 开发 出 撤销 及 重 做 这 两 种 功能 。 
口 并 发 安全 。 传 统 的 并 发 非常 难 做 ， 因 为 要 人 处理 各 种 数据 不 一 致 的 问题 ， 所 以 “聪明 人 ” 
发 明了 各 种 锁 来 解决 。 但 使 用 了 Immutable 之 后 ,数据 天 生 是 不 可 变 的 ,并 发 锁 就 不 再 需 
要 了 。 然 而 现在 并 没有 用 ， 因 为 JavaScript 还 是 单线 程 运行 的 。 
口 拥抱 函数 式 编程 。Immnutable 本 身 就 是 函数 式 编程 中 的 概念 。 只 要 输入 一 致 ， 输 出 必然 一 
致 ， 这 样 开 发 的 组 件 更 易于 调试 和 组 装 。 
像 ClojureScript 、Elm 等 函数 式 编程 语言 中 的 数据 类 型 天 生 都 是 不 可 变 的 ， 这 也 是 基于 
ClojureScript 的 React 框架 Om 性 能 比 React 好 的 原因 。 
3. 使 用 Immutable 的 缺点 
容易 与 原生 对 象 混淆 是 使 用 Immutable 的 过 程 中 遇 到 的 最 大 的 问题 。 
虽然 Inmutable 尽量 把 API 设计 的 原生 对 象 类 似 ， 但 还 是 很 难 区 分 到 底 是 Inmutable 对 象 还 
是 原生 对 象 。 
Immutable 中 的 Map 和 List 虽然 对 应 的 是 JavaScript 的 0bject 和 Array， 但 操作 完全 不 同 ， 
比如 取 值 时 要 用 map.get('key') 而 不 是 map.key， 要 用 array.get(0) 而 不 是 array[0]。 男 外 ， 
Immutable 每 次 修改 都 会 返回 新 对 象 ， 很 容易 忘记 赋值 。 
当 使 用 第 三 方 库 的 时 候 ， 一 般 需 要 使 用 原生 对 象 ， 同 样 容易 忘记 转换 对 象 。 下 面 给 出 一 些 办 
法 来 避免 类 似 问题 的 发 生 : 
口 使 用 FlowType 或 TypeScript 静态 类 型 检查 工具 ; 
口 约定 变量 命名 规则 ， 如 所 有 Immutable 类 型 对 象 以 $$ 开头 ; 
口 使 用 Immutable.fromJs 而 不 是 Immutable.Map 或 Immutable.List 来 创建 对 象 ， 这 样 可 以 
避免 Immutable 对 象 和 原生 对 象 间 的 混用 。 
4. Immutable.is 


两 个 Inmutable 对 象 可 以 使 用 === 来 比较 ， 这 样 是 直接 比较 内 存 地 址 ， 其 性 能 最 好 。 但 是 
即使 两 个 对 象 的 值 是 一 样 的 ， 也 会 返回 false: 
let map1 = Immutable.Map({a:1, b:1, c:1}); 


let map2 = Immutable.Map({a:1, b:1, c:1}); 
map1 === map2; // => false 
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为 了 直接 比较 对 象 的 值 ，Immutable 提供 了 Immutable.is 来 作 “ 值 比较 ”: 


Immutable.is(map1l, map2); // => true 


Immutable.is 比较 的 是 两 个 对 象 的 hashcode 或 value0f ( 对 于 JavaScript 对 象 ) 。 由 于 
Immutable 内 部 使 用 了 trie 数据 结构 来 存储 ， 只 要 两 个 对 象 的 hashCcode 相等 ， 值 就 是 一 样 的 。 
这 样 的 算法 避免 了 深度 遍历 比较 ， 因 此 性 能 非常 好 。 

另外 ， 还 有 mori、cortex 等 库 。 因 为 它们 与 Immutable.is 类 似 ， 所 以 这 里 就 不 再 一 一 介 















































5. Immutable 与 cursor 


这 里 的 cursor 和 数据 库 中 的 游标 是 完全 不 同 的 概念 。 由 于 Immutable 数据 一 般 舱 套 非常 深 ， 
所 以 为 了 便于 访问 深层 数据 ，cursor 提供 了 可 以 直接 访问 这 个 深层 数据 的 引用 : 



































import Immutable from 'immutable'; 
import Cursor from 'immutable/contrib/cursor'; 


let data = Immutable.fromJS({ a: { b: {c: 1 

// 让 cursor 指向 {c:1} 

let cursor = Cursor.from(data, ['a', 'b'], newData => { 
// 当 cursor 或 其 子 cursor 执行 更 新 时 调用 


console. log(newData); 


}); 


cursor.get('c'); // 1 
cursor = cursor.update('c', x => x + 1); 
cursor.get('c'); // 2 


6. Immutable 与 PureRender 

前 面 已 经 介绍 过 ，React 做 性 能 优化 时 最 常用 的 就 是 shouLdComponentUpdate 方法 ， 但 它 默 
认 返 回 true, 即 始终 会 执行 render 方法 , 然后 做 Virtual DOM 比较 , 并 得 出 是 否 需 要 做 真实 DOM 
的 更 新 ， 这 里 往往 会 带 来 很 多 没 必要 的 演 染 。 

当然 ， 我 们 也 可 以 在 shouldComponentUpdate 中 使 用 深 拷贝 和 深 比 较 来 避免 无 必要 的 render， 
但 深 拷 贝 和 深 比 较 一 般 都 是 非常 昂贵 的 选择 。 

Immutable.js 则 提供 了 简洁 、 高 效 的 判断 数据 是 否 变 化 的 方法 ， 只 需 === 和 is 比较 就 能 知 
道 是 否 需 要 执行 render ， 而 这 个 操作 几乎 零 成 本 ， 所 以 可 以 极 大 提高 性 能 。 修 改 后 的 
shouldComponentUpdate 是 这 样 的 : 























import React, { Component } from 'react'; 
import { is } from 'immutable'; 


class App extends Component { 
shouldComponentUpdate(nextProps, nextState) { 
const thisProps = this.props || QQ}; 
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const thisState = this.state || {}; 


if (Object.keys(thisprops).length !== 0bject.keys(nextProps).Length || 
Object.keys(thisState).length !== Object.keys(nextState).length) { 
return true; 


} 


for (const key in nextProps) { 
if (nextProps.hasOwnProperty(key) && 
!is(thisprops[key], nextProps[key])) { 
return true; 
} 
} 





for (const key in nextState) { 
if (nextState.hasOwnProperty(key) && 
!is(thisState[key], nextState[key])) { 
return true; 


} 
} 


return false; 
} 
} 


使 用 Immutable 后 ， 当 灰色 节点 的 state 变化 后 , 不 会 再 演 染 树 中 的 所 有 节点 ,而 是 只 演 染 图 
右 侧 灰色 的 部 分 ， 如 图 2-4 所 示 。 





























图 2-4 Immutable 演 梁 


7. Immutable 与 setState 
React 建议 把 this.state 当 作 不 可 变 的 ， 因 此 修改 前 需要 做 一 个 深 拷贝 : 


import React, { Component } from 'react'; 
import '_' from 'lodash'; 


class App extends Component { 
constructor(props) { 
super(props); 
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this.state = { 
data: { times: 0 }, 
} 
} 


handleAdd() { 
Let data = _.cloneDeep(this. state. data); 
data.times = data.times + 1; 
this.setState({ data: data }); 
// 如 果 上 面 不 做 cloneDeep， 下 面 打印 的 结果 会 是 加 1 后 的 值 
console.log(this. state. data. times); 

} 

} 


但 在 使 用 Immutable 后 ， 操 作 变 得 很 简单 : 





import React, { Component } from 'react'; 


class App extends Component { 
constructor(props) { 
super(props); 


this.state = { 
data: Map({ times: 0 })， 
} 
} 


handleAdd() { 
this.setState(({ data }) => ({ 
data: data.update('times', v => v + 1), 
})); 
// 这 时 的 times 并 不 会 改变 
console.log(this.state.data.get( 'times')); 
} 
} 


Immutable 可 以 给 应 用 带 来 极 大 的 性 能 提升 , 但 是 否 使 用 还 要 看 项 目 情 况 。 由 于 侵入 性 较 强 ， 
新 项 目 引 入 比较 容易 , 老 项 目 迁 移 需 要 谨慎 地 评估 迁移 成 本 。 对 于 一 些 提供 给 外 部 使 用 的 公共 组 
件 ， 最 好 不 要 把 Immutable 对 象 直接 暴露 在 对 外 的 接口 中 。 






































2.6.4 key 
写 动态 子 组 件 的 时 候 ， 如 果 没 有 给 动态 子 项 添加 key prop ， 则 会 报 一 个 警告 ; 


Warning: Each child in an array or iterator should have a unique "key" prop. Check the render method 
of 'App'. See https://fb.me/react-warning-keys for more information. 


、 指 的 是 , 如 果 每 一 个 子 组 件 是 一 个 数组 或 迭代 絮 的 话 , 那么 必须 有 一 个 唯一 的 key prop。 
个 key prop 究竟 是 做 什么 的 呢 ? 


























2.6 组 件 性 能 优化 109 








我 们 想象 一 下 ， 假 如 需要 泻 染 一 个 有 5000 项 的 成 绩 排 名 榜 单 ， 而 且 每 隔 几 秒 就 会 更 新 一 次 
排名 ， 其 中 大 部 分 排名 只 是 位 置 变 了 ,还 有 少 部 分 的 是 完全 更 新 了 ， 少 部 分 则 是 清 出 榜 单 了 。 


此 时 key 就 发 挥 作 用 了 ， 它 是 用 来 标识 当前 项 的 唯 


我 们 有 一 份 学 生 的 成 绩 数组 


[{ 
sid: '600211', 
name: 'Cam', 


}; 
sid: '600243', 


name: 'Arcthur ' ， 


sid: '600225' ， 
name: "Echo ' ， 




















Ee 











其 中 ，sid 是 学 号 ，name 是 名 字 。 那 么 ， 我 们 来 实现 成 绩 排名 的 榜 单 : 


import React from 'react'; 


function Rank({ list }) { 
return ( 
<ul> 
{list.map((entry, index) => ( 
<li key={index}>{entry.name}</li> 
))} 
</ul> 
); 
} 


生 的 props。 现 在 尝试 来 描述 这 一 场景 ， 





我 们 把 key 设 成 了 序号 , 这 么 做 的 确 不 会 报警 告 了 ,但 这 是 非常 低 效 的 做 法 。 我 们 在 生产 环 
境 下 常常 犯 这 样 的 错误 ， 这 个 key 是 每 次 用 来 做 Virtual DOM diff 的 ， 每 一 位 同学 都 用 序号 来 更 
新 的 问题 是 它 没 有 和 同学 的 唯一 信息 相 匹配 , 相当 于 用 了 一 个 随机 键 ,那么 不 论 有 没有 相同 的 项 ， 








更 新 都 会 重新 泻 染 。 





正确 的 做 法 也 很 简单 ， 只 需要 把 key 的 内 容 换 成 sid 就 可 以 了 : 


import React from 'react'; 


function Rank({ list }) { 
return ( 
<UL> 
{list.map((entry, index) => ( 


<li key={entry.sid}>{entry.name}</li> 


))} 

</ul> 

); 
} 


当 key 相同 时 ，React 会 怎么 泻 染 呢 ? 答案 是 


只 浑 染 第 一 个 相同 key 的 项 ， 且 
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Warning: fLattenChiLdren(.…): Encountered two children with the same key, ‘ .$a . Child keys must be unique; 
when two children share a key, only the first child will be used. 


因此 ， 对 key 有 一 个 原则 ， 那 就 是 独一无二 ， 且 能 不 用 遍历 或 随机 值 就 不 用 ， 除 非 列 表 内 容 
也 并 不 是 唯一 的 表示 ， 且 没有 可 以 相 匹 配 的 属性 。 

关于 key， 我 们 还 需要 知道 的 一 种 情况 是 ， 有 两 个 子 组 件 需要 泻 染 的 时 候 ， 我 们 没 法 给 它们 
设 key。 这 时 需要 用 到 React 插件 createFragment 来 解决 . 


















































import React from 'react'; 
import createFragment from 'react-addons-create-fragment'; 


function Rank({ first, second }) { 
const children = createFragment({ 
first: first, 
second: second, 


}); 


return ( 
<ul> 
{children} 
</ul> 
); 
} 


上 述 代码 中 ，first 和 second 两 个 prop 的 key 就 是 我 们 设置 对 象 的 key。 








2.6.5 react-addons-perf 


做 了 这 么 多 工作 , 怎么 才能 量化 以 上 所 做 的 性 能 优化 的 效果 呢 ? 这 里 介绍 一 个 性 能 检测 工具 
来 帮助 我 们 找到 应 用 的 性 能 瓶颈 之 所 在 。 

react-addons-perf 是 官方 提供 的 插件 。 通 过 Perf.start() 和 perf.stop() 两 个 API 设置 
开始 和 结束 的 状态 来 作 分 析 。 它 会 把 各 组 件 泻 染 的 各 个 阶段 的 时 间 统 计 出 来 ， 然 后 打印 出 一 
张 表 格 。 

react-addons-perf 可 以 打印 组 件 泻 染 的 各 个 阶段 ， 如 图 2-5 所 示 。 


口 Perf.printInclusive(measurements): 所 有 阶段 的 时 间 。 

口 Perf.printExclusive(measurements): 不 包含 挂 载 组 件 的 时 间 ， 即 初始 化 props 、state， 
调用 componentWillMount 和 componentDidMount 方法 的 时 间 等 。 

口 Perf.printNasted(measurements): 监测 泻 染 的 内 容 保持 不 变 的 组 件 〈 可 以 查看 哪些 组 件 
没有 被 shouLdComponentUpdate 命中 )。 





















































(index) Owner > component Inclusive time (ms) Instances 
9 "<root> > App" 12.19 本 





图 2-5$ react-addons-perf 打印 结果 


2.7 动画 111 























无 论 是 PureRender 还 是 key 值 ， 整 个 React 组 件 的 优化 逻辑 都 是 针对 Virtual DOM 的 更 新 优 
化 。 如 果 需 要 用 到 更 复杂 的 方法 ， 推 荐 先 阅读 第 3 章 ， 深 度 探究 Virtual DOM 的 运行 原理 。 








2.7 动画 

动画 就 是 使 用 页 面 局 部 的 快速 更 新 让 人 们 产生 动态 效果 的 感觉 。 

动画 可 以 帮助 用 户 理解 页 面 ， 增 加 应 用 的 趣味 性 和 可 玩 性 ， 提 高 用 户 体 验 。 有 时 候 ， 一 个 好 
的 加 载 动画 甚至 要 比 优化 数据 库 、 减 少 等 待 时 间 要 有 效 得 多 。 

React 通过 setstate 让 界面 迅速 发 生变 化 ， 但 动画 的 哲学 告诉 我 们 ， 变 化 要 慢 ， 得 用 一 个 逐 
渐变 化 的 过 程 来 过 渡 ， 从 而 帮助 用 户 理解 页 面 。 

界面 的 变化 可 以 分 为 DOM 节点 (或 组 件 ) 的 增 与 减 以 及 DOM 节点 〈 或 组 件 ) 属性 的 变化 。 
其 中 React 提供 的 TransitionGroup 能 够 帮助 我 们 便捷 地 识别 出 增加 或 删除 的 组 件 ， 从 而 让 我 们 能 
够 专注 于 更 加 简单 的 属性 变化 的 动画 。 

关于 JavaScript 动画 与 CSS 动画 的 说 法 不 一 ， 为 了 方便 起 见 ， 这 里 统一 将 缓 动 函 数 通 过 
JavaScript 实现 的 动画 称 作 JavaScript 动画 , 绥 动 函数 由 CSS 提供 (浏览 器 实现 ) 的 动画 称 作 CSS 
动画 。 






























































2.7.1 CSS 动画 与 JavaScript 动画 


总 的 来 说 ， 使 用 CSS 动画 ， 能 够 得 到 更 好 的 性 能 和 更 快 的 开发 效率 。 尽 管 运用 CSS 更 加 方 
便 ， 但 必然 有 其 作为 DSL 的 局 限 性 。 当 磁 到 CSS 的 局 限 性 ， 导 致 用 CSS 无 法 实现 或 者 实现 起 来 
十 分 烦琐 时 ， 就 是 使 用 JavaScript 动画 的 时 候 了 。 


1. CSS 动画 的 局 限 性 
CSS 动画 的 局 限 性 如 下 所 示 。 


口 CSS 只 支持 cubic-bezier 的 缓 动 ， 如果 你 的 动画 对 缓 动 函数 有 要 求 , 就 必须 使 用 JavaScript 
动画 。 

口 CSS 动画 只 能 针对 一 些 特有 的 CSS 属性 。 仍 然 有 一 些 属性 是 CSS 动画 不 支持 的 ， 例 如 
SVG 中 path 的 d 属 性 。 

口 CSS 把 translate、rotate、skew 等 都 归结 为 一 个 属性 transform。 因 此 ， 这 些 属性 只 
能 共用 同一 个 缓 动 函 数 , 例如, 我 们 想 要 动画 的 轨迹 是 一 条 贝 塞 尔 曲线 , 可 以 通过 给 Left 
和 top 这 两 个 属性 加 两 个 不 同 的 cubic-bezier 组 动 来 实现 ， 但 是 Left 和 top 实现 的 动画 性 
能 不 如 translateX 和 translateY。 
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2. CSS animation 

CSS transition 设计 得 非常 简洁 ， 因 此 适用 于 比较 简单 的 动画 。 而 CSS animation 弥补 了 CSS 
transition 在 控制 上 的 不 足 。 利 用 CSS animation， 我 们 可 以 : 
口 使 用 多 步 动 画 ( 多 关键 帧 动画 ); 
口 弥补 CSS transition 在 控制 上 的 不 足 ， 设 置 动画 的 反 转 、 暂 停 、 次 数 (可 以 设置 为 永久 ) 


和 
等 




















3. 用 JavaScript 包装 过 的 CSS 动画 
有 些 文章 也 把 用 JavaScript 包装 过 的 CSS 动画 归结 为 JavaScript 动画 ， 这 样 CSS 动画 的 范畴 
就 太 小 了 。 原 生 的 CSS 动画 可 以 很 方便 地 实现 一 些微 互动 ， 如 : 





eL { 
opacity: 1; 


&:hover { 
opacity: 0.8; 
transition: opacity .4s ease; 


} 
} 


但 是 对 于 大 多 数 情 况 而 言 ， 使 用 原生 CSS 动画 ,流程 比较 烦琐 。 首 先 ， 我 们 要 给 DOM 节点 
在 不 同 状 态 下 加 不 同 的 复杂 的 className 。 然 后 在 CSS 中 给 不 同 的 cLassName 写 不 同 的 样式 以 及 
动画 逻辑 。 这 里 就 有 必要 用 JavaScript 做 一 些 包 装 ， 来 做 一 些 共同 的 逻辑 ， 简 化 动画 的 开发 。 

这 里 我 们 介绍 使 用 react-smooth 库 来 写 动画 。 它 不 仅 支持 CSS 动画 ， 也 支持 各 种 绥 动 类 型 的 
JavaScript 动画 ， 并 且 提 供 定制 化 缓 动 函 数 的 插件 和 人口: 









































<Animate from={1} to={0.8} attributeName="opacity"> 
fy 


</Animate> 


4. JavaScript 动画 

这 里 将 JavaScript 动画 定义 为 缓 动 函 数 用 JavaScript 实现 的 动画 ， 因 此 JavaScript 动画 包含 组 

2.7.3 节 将 详细 说 明 绥 动 函 数 以 及 如 何 用 JavaScript 实现 绥 动 函数 。 而 在 泻 染 部 分 ， 可 以 在 
View 层 利 用 强大 的 React 来 帮助 我 们 渲染 。 这 样 只 要 在 绥 动 函数 中 执行 setState 来 更 新 动画 进 
度 ， 从 而 触发 页 面 重 绘 。 

5. SVG 线条 动画 

说 起 SVG 线条 动画 ,最 出 名 的 钨 怕 是 vivus,js, 它 巧妙 地 利用 了 SVG path 的 stroke-dasharray 
属性 和 getTotalLength 方法 。 
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stroke-dasharray 是 设置 SVG path 虚线 的 属性 。 因 此 ， 要 做 一 个 简单 的 线条 动画 ， 只 需 : 


eL { 
stroke-dasharray: 0, 1px; 





| 


&.active { 
stroke-dashoffset: totalLength, 0; 
transition: stroke-dasharray .4s ease; 
} 
} 


然而 vivus 有 两 个 缺陷 : 


口 它 用 JavaScript 动画 实现 stroke-dasharray 的 组 动 ， 而 实际 上 CSS 动画 是 支持 stroke- 
dasharray 属性 的 ; 
口 vivus 不 支持 虚线 动画 。 


那么 ， 如 何 利 用 stroke-dasharray 来 实现 虚线 动画 呢 ? 


stroke-dasharray， 顾 名 思 义 ， 其 值 其 实 是 一 个 数组 。 因 此 ， 我 们 可 以 利用 这 一 特性 逐渐 改 
变 这 个 数组 的 长 度 ， 如 : 


























1px, Opx; 

2px, Opx; 

2px, 1px; 

2px, 2px, 1px; 
2pX，2pXx，2px; 

2px, 2px, 2pXx, 1px; 
2px, 2pXx, 2pXx, 2pxX; 


2.7.2 玩 转 React Transition 


2015 年 ，React 给 整个 前 端 界 带 来 了 一 种 新 的 开发 方式 , 我 们 抛弃 了 无 所 不 能 的 DOM 操作 。 
对 于 React 实现 动画 这 个 命题 DOM 操作 已 经 是 一 条 死路 ,而 CSS3 动画 又 只 能 实现 一 些 最 简单 
的 功能 。 这 时 候 ReactCSSTransitionGroup 插件 无 疑 是 一 枚 强 心 剂 。 

React 演 染 结果 的 任何 变化 ， 无 非 是 组 件 节 点 的 增 、 添 、 删 除 和 组 件 属性 的 变化 。React 
Transition 帮助 开发 者 识别 组 件 的 子 组 件 们 的 增 与 删 。 下 面 让 我 们 来 谈 谈 React Transition 的 设计 、 
用 法 、 实 现 原理 ， 以 及 基于 React Transition 封装 的 又 一 个 好 工具 React CSS Transition。 


1. React Transition 的 设计 及 用 法 

学 习 API 或 者 用 法 很 简单 ， 但 是 在 学 习 API 的 时 候 ， 我 们 不 妨 也 来 思考 一 下 React Transition 
API 的 设计 ， 说 不 定 会 有 更 多 的 收获 。 

React Transition 如 何 帮 助 开 发 者 识别 增删 的 节点 呢 ? 方法 有 很 多 , 而 React 结合 自己 的 特点 ， 
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设计 了 以 生命 周期 函数 的 方式 来 实现 , 即 让 子 组 件 的 每 一 个 实例 都 实现 相应 的 生命 周期 函数 。 当 
React Transition 识别 到 某 个 子 组 件 增 或 删 时 ， 则 调用 它 相 应 的 生命 周期 函数 。 我 们 可 以 在 生命 周 
期 函数 中 实现 动画 逻辑 。 
事实 上 ， 一 个 组 件 中 所 有 子 组 件 的 增删 动画 逻辑 大 同 小 异 〈 动 效 的 统一 性 )。 如 果 每 一 个 子 
组 件 的 动 效 相同 ， 那 么 每 一 个 子 组 件 可 以 共用 同一 个 生命 周期 函数 。 因 此 ，React Transition 提供 
了 chiLdFactory 配置 ， 让 用 户 自 定义 一 个 封装 子 组 件 的 工厂 方法 ， 为 子 组 件 加 上 相应 的 生命 周 
期 函数 。 

React Transition 提供 了 哪些 生命 周期 呢 ?” 想 想 也 知道 ， 它 们 无 非 是 : 























D componentWillAppear 
DQ componentDidAppear 
口 componentWillEnter 
口 componentDidEnter 


D componentWillLeave 





D componentDidLeave 


componentwiltlxxx 在 什么 时 候 触 发 很 容易 判断 ， 只 需 在 componentWillReceiveProps 中 对 
this.props.children 和 nextProps.children 做 一 个 比较 即 可 。 而 componentDidxxx 要 何 时 触发 呢 ? 


可 以 给 componentWtLLxxx 提供 一 个 回调 函数 ， 用 来 执行 componentDidxxx。 
React Transition 的 API 设计 正 是 这 样 的 ， 你 若 感到 迷惑 ， 可 以 先 来 看 一 个 例子 。 


之 前 说 过 ，React Transition 对 CSS 动画 做 了 封装 ， 因 此 我 们 来 实现 一 个 React Transition 的 
JavaScript 动画 。 在 实现 React Transition 的 childFactory 工厂 方法 的 时 候 ， 我 们 可 以 先 实 现 一 个 
JSTransitionChild 的 类 : 























update(done, now) { 
if (!this.leaveTime) { 
this. leaveTime = now; 


} 


const { duration } = this.props; 
const passedTime = now - this.enterTime; 


if (passedTime > duration) { 
if (this.cafId) { 
caf(this.cafld); 
this. leaveTime = null; 


} 
done(); 


return; 
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const progress = ease(passedTime / duration); 


this.setState({ 
progress, 


}) 


this.cafId = raf(this.enter.bind(this, done)); 
} 


componentWillLeave(done) { 
if (this.cafId) { 
caf(this.cafld); 

this. leaveTime = null; 


} 


raf(this.update.bind(this, done)); 
} 


虽然 我 们 没有 实现 componentDidLeave 函数 ， 但 是 仍然 如 实地 在 正确 的 地 方 执行 了 done 回 
调 ， 确 保 componentDidLeave 执行 。 这 是 为 什么 呢 ? 


componentWillLeave 中 的 回调 函数 ( 即 这 里 的 done ) 有 点 特殊 。 我 们 知道 ，React 动画 归根 
结 底 是 让 状态 变化 变 慢 , 或 者 说 延迟 变化 。 那 么 对 于 消失 的 动画 来 说 ,我们 要 花费 一 段 时 间 展 现 
消失 的 动画 ， 就 必须 让 消失 的 子 组 件 延 迟 消 失 , 在 这 段 时 间 内 暂时 保留 。 因 此 ,这 里 的 回调 函数 
不 仅仅 是 执行 componentDidLeave， 也 执行 了 让 这 个 子 组 件 从 子 组 件 集中 消失 的 操作 。 

2. React CSS Transition 设计 及 用 法 

React Transition 还 对 CSS 动画 做 了 专门 的 封装 。 用 CSS3 来 做 React 动画 简直 完美 ! 我 们 不 
用 像 JavaScript 动画 那样 用 setstate 来 让 状态 延缓 更 新 ，CSS3 中 就 有 让 状态 延迟 更 新 的 方法 。 
我 们 把 延迟 更 新 状态 的 逻辑 交 给 CSS ,不仅 可 以 让 代码 更 加 专注 于 业务 逻辑 ,更 为 简洁 ,还 能 提 
高 动画 的 性 能 。 

React CSS Transition 为 子 组 件 的 每 个 生命 周期 加 了 不 同 的 className ， 这 样 用 户 可 以 很 方便 
地 根据 className 的 变化 来 实现 动画 。 例 如 : 






























































<ReactCSSTransitionGroup 
transitionName="example" 
transitionEnterTimeout={400} 
> 
{items} 
</ReactCSSTransitionGroup> 


对 应 的 SCSS 代码 为 : 


.example-enter { 
transform: scaleY(0); 


&.example-enter-active { 
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transform: scaleY(1); 
transition: transform .4s ease; 


} 
} 


这 样 便 轻松 地 实现 了 items 中 新 增 元 素 的 动画 。 


在 使 用 React Transition 时 ， 如 何 设 定子 组 件 集 的 key 也 颇 有 学 问 ， 毕 竟 代 表 一 个 元 素 的 不 是 
它 的 位 置 ， 而 是 它 的 key 值 。 


例如 : 我 们 要 展现 10 年 来 GDP 排名 前 10 的 省 份 ， 把 动画 加 在 某 个 名 次 省 份 发 生 更 新 的 元 
素 上 ， 此 时 可 以 把 key 设置 为 {名 次 }-${ 省 份 1d}。 


当然 ， 如 果 使 用 react-smooth 来 实现 ， 会 更 简洁 : 
































const enter = { 
from: 'scaleY(0)', 
to: 'scaleY(1)', 
attributeName: 'transform', 
duration: 400 ， 

}; 

// 支持 列表 动画 

<AnimateGroup enter={enter}> 
{items} 

</AnimateGroup> 


2.7.3” 缓 动 函 数 
虽然 CSS 动画 简单 易 用 而 且 性 能 高 , 但 是 JavaScript 动画 依然 有 其 必要 性 , 而 且 也 非常 重要 。 
而 谈 到 JavaScript 动画 ， 不 得 不 说 一 说 缓 动 隐 数 。 
缓 动 函 数 是 什么 ， 它 是 一 个 返回 当前 帧 动画 进度 的 函数 。 
1. 缓 动 函数 用 户 体验 


从 动画 体验 的 角度 来 说 , 不 同 的 缓 动 孔 数 会 带 给 用 户 不 同 的 缓 动 体验 。 以 我 们 常见 的 缓 动 函 
数 Linear 、ease 和 spring 为 例 ， 绥 动 体验 一 般 为 Linear < ease < spring。 
为 什么 这 么 说 呢 ? Linear 、ease 和 spring 其 实 刚 好 代表 3 种 缓 动 函数 类 型 。 其 中 ,linear 是 


一 种 匀速 运动 , 给 人 的 感觉 是 机 械 、 呆 板 、 没 有 生机 , 只 有 工厂 里 的 机 器 是 保持 速度 一 成 不 变 的 ! 
人 们 喜欢 有 生命 的 运动 。 


ease 、spring 都 是 变速 运动 ， 那 么 为 什么 spring 的 缓 动 体验 要 比 ease 更 好 呢 ? 物理 原则 是 
优秀 用 户 体验 (UX ) 的 核心 原则 之 一 ， 界 面 设计 遵从 物体 在 真实 世界 中 的 运动 规律 ， 会 让 人 们 
感觉 更 加 自然 、 舒 适 。 


spring 是 最 经 常用 的 物理 缓 动 过 程 。 而 cubic-bezier ( 三 次 贝 塞 尔 曲 线 ) 因为 具有 很 
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强 的 控制 能 力 ， 人 们 可 以 非常 简单 、 直 观 地 配置 一 条 y - t 曲线 作为 缓 动 过 程 。 因 此 ，spring 和 
cubic-bezier ( 如 ease、ease-in 、ease-out 、ease-in-out、Linear ) 在 动画 中 最 为 常用 。 所 以 下 

















面 先 以 spring 为 例 探 讨 一 种 通用 的 物理 缓 动 的 实现 方法 ， 然 后 谈 谈 如 何 实现 cubic-bezier 的 组 动 
过 程 。 
2. 物理 缓 动 


根据 经 典 力学 的 观点 , 世界 上 所 有 的 原子 每 时 每 刻 仿 佛 都 会 根据 当前 速度 、 受 力 和 位 置 计算 
出 下 一 刻 的 速度 、 受 力 和 位 置 。 上 帝 有 一 台 超 级 计算 机 吗 ? 非 也 , 计算 机 反而 是 我 们 利用 原子 的 
这 些 特性 拼装 出 来 的 。 不 过 现在 ， 我 们 要 用 计算 机 ， 像 上 帝 那 样 再 造 一 个 世界 。 


物理 缓 动 是 模仿 现实 世界 物体 运动 的 缓 动 , 我 们 可 以 先 模拟 物理 规律 ,然后 用 最 简洁 的 物理 
法 则 的 表述 方式 一 一 物理 公式 来 计算 物体 状态 。 一 个 简单 的 思路 跃然 纸 上 : 
口 在 每 一 帧 中 对 动画 对 象 进行 受 力 分析 ， 计 算 该 帧 动画 对 象 的 加 速度 ; 
口 如 果 知 道 该 帧 的 速度 、 位 置 ， 就 可 以 根据 该 帧 的 加 速度 、 速 度 、 位 置 ， 计 算 下 一 帧 的 速 
度 、 位 置 ; 
口 当 我 们 知道 第 一 帧 的 速度 和 位 置 ， 就 可 以 像 多 米 诺 骨牌 那样 算出 动画 对 象 每 一 帧 的 位 置 ! 
任何 物理 缓 动 都 可 以 这 样 完成 ! 
@ 模拟 物理 规律 
以 spring 为 例 ， 我 们 先 来 描述 一 下 其 物理 环境 。 
有 一 个 弹簧 , 弹簧 上 绑 了 一 个 夸 码 , 奢 码 在 运动 的 时 候 受 到 空气 阻力 (空气 阻力 Fuanpins 与 夸 
码 当前 的 速度 w 呈 正 相关 )。 
@ 受 力 分 析 
回 到 初中 物理 ， 根 据 胡 克 定 律 ， 夸 码 受到 弹簧 的 拉力 为 : 
Ra = KAx (大 为 弹簧 的 劲 度 系 数 ) 
我 们 假设 该 夸 码 受到 的 空气 阻力 的 阻尼 系数 为 斥 
对 夸 码 进行 受 力 分 析 ， 得 到 ; 



















































































amping 2 


VO 二 大 二 三 大 


spring damping Spring damping 1 
@ 建立 相 邻 两 帧 前 后 物理 状态 的 关系 式 
设 w% 为 在 码 当 前 加 速度 ， 得 到 : 
F=ma, 


设 v 和 x 分 别 为 经 过 dt 时 间 后 ， 硅 码 新 的 速度 和 位 移 ， 得 到 : 














二 芒 
a, =lim— = lim 
d=»0 dt d=o0 dt 
了 
X 一 其 
vy,=lim— = 1im ! 





即 : 
v'=lima,*dt+y, 
di 一 0 


2X = limyv, *dt+x, 
dr 一 0 

















然而 这 并 不 是 相 邻 两 帧 前 后 物理 状态 的 关系 式 子 ， 因 为 dt 不 是 一 帧 的 时 间 ， 而 是 无 限 小 。 

幸好 我 们 可 以 知道 当 dt 越 趋 近 于 0 时 ， 等 式 两 边 的 值 越 接 近 ( 极限 的 单调 有 界 性 )。 

别 忘 了 我 们 不 是 来 做 物理 实验 的 ， 我 们 的 目的 是 做 一 个 能 够 骗 过 人 类 眼睛 的 物理 运动 过 程 。 
因此 ， 我 们 可 以 把 dt 设置 为 一 个 很 小 的 常量 值 来 拟 合 这 个 运动 过 程 ， 把 等 号 变 成 约 等 号 (设置 
为 常量 也 是 为 了 降低 误差 )。 
越 来 越 接 近 了 ! 然而 这 里 还 有 一 个 小 小 的 波折 : 这 个 很 小 的 常量 dt 的 值 也 不 是 一 帧 的 时 间 。 
简单 地 说 ， 我 们 可 以 用 dt 去 拼凑 一 帧 的 时 间 〈 以 下 表述 为 Ar )， 如 图 2-6 所 示 。 
















































































图 2-6 ”拼凑 帧 原理 

















当 At 不 是 dt 的 整数 倍 时 ， 最 后 多 出 来 的 那 一 小 块 时 间 可 以 用 一 个 简单 的 插值 算法 ， 比 如 线 
性 插值 ， 来 计算 那 一 小 块 时 间 的 物理 状态 改变 量 。 
至 此 ,一 个 简单 的 Web 动画 物理 引擎 就 实现 了 。 


万 变 不 离 其 宗 ， 这 里 spring 只 是 一 个 简单 的 例子 。 使 用 这 种 通用 的 模拟 物理 规律 的 方法 ， 
我 们 可 以 实现 任意 物理 动画 的 缓 动 ， 比 如 一 个 复杂 而 炫 酷 的 用 threejs 实现 的 动画 ”。 


现在 ， 我 们 利用 react-smooth 来 实现 弹簧 动画: 























<Animate from={{left: 0}} to={{left: 10}} ease="spring"> 
{style => <div style={style}>test</div>} 
</Animate> 


不 过 说 到 spring 动画 ， 不 得 不 提起 react-motion 库 。 下 面 是 使 用 react-motion 库 实现 一 个 开 











GD webgl animation cloth， 详 见 http://threejs.org/examples/#webgl]_animation _ cloth。 
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关 的 例子 : 
import React, { Component } from 'react'; 


class Switch extends Component { 
constructor(props) { 
super(props); 





this.handleClick = this.handleClick.bind(this); 


this.state = { 
open: false, 
}; 
} 


handleClick() { 
this.setState({ 
open: !this.state.open, 


]); 
} 
render() { 
return ( 
<Motion style={{x: spring(this.state.open ? 400 : 0)}}> 
{({x}) => 
<div className="demo"> 
<div 
className="demo-block" 
onClick={this.handleClick} 
style={{ 
transform: ‘translate3d(${x}px, 0, 0).，, 
}} 
/> 
</div> 
} 
</Motion> 
); 
} 


} 

3. cubic-bezier 缓 动 

物理 动画 固然 炫 酷 ， 但 是 cubic-bezier 同样 是 一 个 非常 优秀 的 组 动 过 程 

cubic-bezier 可 以 非常 直观 、 方 便 地 配置 一 条 变速 运动 的 缓 动 曲线 。 由 于 CSS 原生 提供 cubic- 
bezier 的 组 动 图 数 ， 所 以 cubic-bezier 在 Web 动画 中 得 到 大 量 使 用 。 

然而 ， 由 于 CSS 这 种 DSL 的 局 限 性 ， 我 们 经 常 不 得 不 用 程序 语言 来 实现 一 个 缓 动 过 程 。 举 
一 个 最 简单 的 例子 ， 由 于 CSS 的 缓 动 只 能 作用 于 值 类 型 的 CSS 属性 ， 所 以 假设 要 根据 某 种 规则 
对 SVG path 的 d 属性 做 动画 ，CSS 便 毫 无 用 武之 地 。 此 时 人 们 往往 会 用 丑陋 的 Linear 缓 动 实现 

一 个 JavaScript 动画 ， 说 好 的 变速 运动 呢 ? 
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因此 ， 有 必要 用 程序 语言 实现 一 个 cubic-bezier。 
@ cubic-bezier 函数 表达 式 
我 们 先 来 看 看 cubic-bezier 的 函数 表达 式 : 





(x,y) = fi +37°(1—0) (x, 7)+3t1 一 人 (2) + (0) 




















乍 看 之 下 ,我们 可 能 会 觉得 这 个 问题 非常 简单 ， 上 式 不 就 是 cubic-bezier 的 缓 动 函数 吗 ? 

当然 不 是 这 么 简单 ， 我 想 你 已 经 发 现 了 ， 此 ! 非 彼 上。cubic-bezier 的 缓 动 过 程 的 时 间 是 
尔 曲线 的 x 坐标 ， 也 就 是 式 中 的 x。 

也 就 是 说 ， 我 们 要 根据 这 个 (x,y)= f(1) (或 者 说 x= 了 (D),y= 了 (1) )， 得 到 x 一 的 函数 。 

假设 x 一 t 大 的 反 孙 数 为 1 一 x:g， 即 : 


t= g(x) 

















1 塞 


As 


y=f,(D)= f,(8(7)) 

















所 以 问题 简化 为 求 的 反 函 数 , 或 者 说 解 方 程 ,可 是 这 个 一 元 三 次 方程 与 大 多 数 方程 一 样 ， 不 存 
在 求 根 公式 。 所 以 ， 我 们 只 能 用 区 间 通 近 的 方法 来 求 近似 解 。 

换 成 计算 机 术语 来 说 , 任何 数学 函数 都 是 程序 语言 中 的 纯 函 数 , 任何 纯 函 数 都 可 以 当成 一 个 
散 列 表 ， 表 中 的 键 是 参数 ， 表 中 的 值 是 函数 返回 结果 。 我 们 知道 上 这 个 函数 都 是 单调 递增 的 ， 也 
就 是 说 ， 这 个 表 是 已 经 排序 的 ， 所 以 可 以 用 最 简单 的 二 分 查找 方法 ， 不 断 缩减 1 的 范围 ， 从 而 求 
出 在 一 定 精度 内 的 t 的 值 。 

为 了 提高 时 间 复 杂 度 和 动画 性 能 ,我 们 可 以 优化 这 个 区 间 通 近 的 方法 , 即 根据 曲线 的 导数 ( 即 
x 在 某 个 时 刻 的 变化 率 ) 来 更 合理 地 逼近 区 间 。 


















































说 明 读者 可 以 查阅 牛顿 法 "和 泰勒 级 数 2 的 相关 数学 知识 ， 使 用 cubic-bezier 的 二 阶 导 和 三 阶 导 
(四 阶 导 开始 为 0 )， 进 一 步 提高 时 间 复 杂 度 。 




















或 许 CSS 只 提供 了 cubic-bezier 也 是 考虑 到 了 其 实现 较为 复杂 ， 属 于 计算 密集 型 ， 并 不 适合 
用 JavaScript 来 实现 。 但 经 我 们 实验 统计 后 发 现 ，JavaScript 版 cubic-bezier 函数 平均 计算 时 间 仅 
为 0.33 ms。 








GD Newton's method， 详 见 https://en.wikipedia.org/wiki/Newton%27s_method。 
@) Taylor series， 详 见 https:/Wen.wikipedia.org/wiki/Taylor_ series。 
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利用 react-smooth 实现 cubic-bezier 动画 的 代码 如 下 : 


<Animate from={{left: 0}} to={{left: 10}} ease="ease'"> 
{style => <div style={style}>test</div>} 
</Animate> 
要 开发 出 好 的 动画 , 我 们 不 仅 要 懂 动 画 的 设计 , 要 有 基本 的 数值 分 析 及 图 形 图 像 学 知识 , 更 
重要 的 还 是 要 能 写 出 优雅 的 、 可 维护 的 、 易 扩展 的 代码 。 


























2.8 上 自动 化 测试 


测试 可 以 让 项 目 保持 健壮 ， 在 后 期 维护 和 扩展 的 过 程 中 ， 减 少 犯错 的 几率 。 当 项 目 发 布 时 ， 
代码 能 通过 所 有 测试 也 代表 所 覆盖 到 的 场景 全 部 通过 。 自 动 化 测试 就 是 把 整个 流程 自动 化 , 代替 
复杂 的 人 工 点 击 。 同 时 通过 配置 回调 钧 子 , 可 以 让 测试 定期 执行 或 在 每 次 发 布 前 执行 。 自 动 化 测 
试 包含 很 多 内 容 ， 本 节 主 要 指 对 React 演 染 的 UI 层 功能 的 自动 化 测试 。 

写 测 试 之 前 需要 了 解 测试 工具 。 首 先 需 要 一 个 测试 执行 锅 , 用 于 执行 测试 用 例 , Mocha 是 最 
流行 的 测试 执行 器 之 一 。 除 此 之 外 ， 还 要 使 用 Chai 等 库 来 做 测试 断言 。 熟 悉 这 两 个 工具 后 ， 我 
们 就 可 以 搭建 完整 的 测试 环境 了 。 


React 对 测试 有 完善 的 支持 ， 目 前 比较 完善 的 React 测试 框架 有 Jest 和 Enzyme， 下 面 会 介绍 
这 两 个 框架 。 

































































2.8.1 Jest 


Jest 是 由 Facebook 开源 的 React 单元 测试 框架 ， 内 部 DOM 操作 基于 JSDOM， 语 法 和 上 断言 
基于 Jasmine 框架 。 它 有 以 下 4 个 特点 : 
口 自动 找到 测试 ; 
口 自动 mock 模拟 依赖 包 ， 达 到 单元 测试 的 目的 ; 
口 并 不 需要 真实 DOM 环境 执行 ， 而 是 JSDOM 模拟 的 DOM; 
口 多 进程 并 行 执行 测试 。 

当 使 用 Jest 来 测试 React 组 件 时 ， 还 要 引入 react-addons-test-utils 插件 ， 用 于 模拟 浏览 器 事件 
和 对 DOM 进行 校 验 。 它 提供 的 常用 方法 如 下 。 
口 Simulate. {eventName} (DOMELement eLement，[object eventData]) : 模拟 触发 事件 。 
口 renderIntoDocument(ReactELement instance): 渔 染 React 组 件 到 文档 中 ， 这 里 的 文档 节 
点 由 JSDOM 提供 。 
口 findRenderedDOMComponentWithClass(ReactComponent tree，string className): 从 演 染 

的 DOM 树 中 查找 含有 class 的 节点 。 
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口 findRenderedDOMComponentWithTag(ReactComponent tree, function componentClass): 从 


演 染 的 DOM 树 中 找到 指定 组 件 的 节点 。 
1. Jest 实例 
我 们 以 第 1 章 的 Tabs 组 件 为 例 来 写 一 个 测试 用 例 。 首 先 ， 我 们 需要 测试 演 染 出 的 Tab 内 容 : 


// ./_test_ /tab-test.js 
jest.unmock('../tab.js'); 








import React from 'react'; 

import ReactDOM from "react-dom'; 

import TestUtils from 'react-addons-test-utils'; 
import Tab from '../Tab'; 


describe('Tab', () => { 
it('render the tab content', () => { 
// 根据 data 澄 染 出 Tab 内 容 
const tab = TestUtiLs.renderIntoDocument( 
<Tabs classPrefix={'tabs'} defaultActiveIndex={0} className="ui-tabs"> 
<TabPane order="0"”tab={'Tab 1'}> 第 一 个 Tab 里 的 内 容 </TabPane> 
<TabPane order="1"” tab={'Tab 2'}> 第 二 个 Tab 里 的 内 容 </TabPane> 
<TabPane order="2"” tab={'Tab 3'}> 第 三 个 Tab 里 的 内 容 </TabPane> 
</Tabs> 
); 


const tabNode = ReactDOM.findDOMNode(tab); 


// 验证 泻 染 出 3 个 Tab 
expect(tab.querySelectorAll(' .tabs-tab').length).toEqual(3); 
// 验证 默认 选中 第 一 个 Tab， 即 索引 为 0 的 子 元 素 含有 active 的 class 
expect(tab.querySelectorAll(' .tabs-tab')[0].classList.contains('tabs-active')).toBe(true); 
}); 
]); 


验证 了 泻 染 后 ， 还 需要 验证 点 击 后 能 切换 到 新 的 Tab: 


describe('Tab', () => { 
it('changes active tab after click', () => { 
const tab = TestUtils.renderIntoDocument( 
<Tabs classPrefix={'tabs'} defaultActiveIndex={0} className="ui-tabs"> 
<TabPane order="0"”tab={'Tab 1'}> 第 一 个 Tab 里 的 内 容 </TabPane> 
<TabPane order="1"” tab={'Tab 2'}> 第 二 个 Tab 里 的 内 容 </TabPane> 
<TabPane order="2"” tab={'Tab 3'}> 第 三 个 Tab 里 的 内 容 </TabPane> 
</Tabs> 
); 


// 模拟 点 击 第 三 个 标签 
TestUtils.Simulate.click( 
tab .querySeLectorALL(' .tabs-tab' )[2] 
3 
// 第 一 个 标签 取消 选中 ， 第 三 个 标签 被 选中 
En .tabs-tab ')[0].classList.contains('tabs-active')).toBe(false); 
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expect(tab.querySelectorAll(' .tabs-tab')[2].classList.contains('tabs-active')).toBe(true); 
]); 

]); 

综 上 , 使 用 Jest 测试 组 件 非常 容易 。 它 既 可 以 模拟 浑 染 DOM 节点 , 也 可 以 模拟 触发 DOM 事 
件 。 在 大 部 分 情况 下 ， 它 已 经 很 好 用 。 

2. 浅 泻 染 机 制 

浅 泻 染 (shallow rendering ) 很 有 趣 ， 意 思 就 是 只 泻 染 组 件 中 的 第 一 层 ， 这 样 测试 执行 器 就 
不 需要 关心 DOM 和 执行 环境 了 。 

在 实际 开发 中 , 组 件 的 层级 非常 深 , 所 以 测试 顶层 组 件 时 ， 如 果 需 要 把 所 有 子 组 件 全 部 泻 染 
出 来 ， 成 本 变 得 非常 高 。 因 为 React 组 件 良 好 的 封装 性 ， 测 试 组 件 时 ， 大 部 分 测试 只 需要 关注 组 
件 本 身 ， 它 的 子 组 件 测 试 应 该 在 子 组 件 对 应 的 测试 代码 里 做 。 这 样 测试 执行 得 很 快 。 

但 浅 泻 染 也 有 天 生 缺 点 ， 它 只 能 测试 一 级 节点 。 如 果 要 测试 子 级 节点 ， 那 就 只 能 做 全 演 染 。 

假如 一 个 组 件 内 部 有 个 非常 复杂 的 子 组 件 ComplexComponent: 


<div> 
<span className="heading">Title</span> 
<ComplexComponent foo="bar" /> 

</div> 


做 浅 演 染 测试 是 这 样 的 : 


let renderer = ReactTestUtils.createRenderer(); 
result = renderer.getRenderOutput(); 





























expect(result. type).toBe('div'); 
expect(result.props.children).toEqual([ 
<span className="heading">Title</span>, 
<ComplexComponent foo="bar" />， 
]); 
3. 全 泻 染 机 制 
全 泻 染 (full rendering ) 就 是 完整 浑 染 出 当前 组 件 及 其 所 有 的 子 组 件 ， 就 像 在 真实 浏览 器 中 
泻 染 那样 。 当 组 件 内 部 直接 改变 了 DOM 时 ， 就 需要 使 用 全 泻 染 来 测试 。 全 泻 染 需要 真实 地 模拟 
DOM 环境 ， 流 行 的 做 法 有 以 下 几 种 。 
口 使 用 JSDOM: 使 用 JavaScript 模拟 DOM 环境 ， 能 满足 90% 的 使 用 场景 。 这 是 Jest 内 部 
所 使 用 的 全 演 染 框架 。 
口 使 用 Cheerio: 类 似 JSDOM， 更 轻 的 实现 ， 类 似 jQuery 的 语法 。 这 是 Enzyme 内 部 使 用 
的 全 演 染 框架 。 
D 使 用 Karma: 在 真实 的 浏览 器 中 执行 测试 ， 也 支持 在 多 个 浏览 器 中 依次 执行 测试 ， 使 用 
的 是 真实 DOM 环境 ， 但 速度 稍 慢 。 
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2.8.2 Enzyme 




















Enzyme 是 由 Airbnb 开源 的 React 组 件 测试 框架 。 与 Jest 相 比 ，Enzyme 提供 类 似 jQuery 操 
作 DOM 的 语法 ， 在 做 测试 断言 时 更 灵活 、 易 用 。React 官方 正 讨论 用 Enzyme 替代 TestUtils ， 这 
也 许 在 下 一 版 中 就 会 实现 。 

Enzyme 提供 3 种 不 同 的 方式 来 测试 组 件 。 
口 shallow: 推荐 的 方式 ， 浅 演 染 ， 只 会 演 染 本 组 件 内 容 ， 引 用 的 外 部 组 件 不 会 渲染 ， 提 供 
更 多 好 的 隔离 性 。 
D render: 如 果 shallow 不 能 满足 , 才 会 使 用 它 。 基 于 Cheerio 来 模拟 DOM 环境 ( Cheerio 是 
类 似 JSDOM 的 另 一 框架 )。 
口 mount: 类 似 render， 会 做 全 渲染 ， 对 于 测试 生命 周期 时 非常 有 用 。 
使 用 Enzyme 做 上 述 Tab 测试 的 代码 如 下 : 


















































import React from 'react'; 

import { shallow } from "enzyme '; 
import Tab from '../Tab'; 

import { expect } from 'chai'; 


describe('Tab', () => { 
it('render the tab content', () => { 
const tab = shallow( 
<Tabs classPrefix={'tabs'} defaultActiveIndex={0} className="ui-tabs"> 
<TabPane order="0"”tab={'Tab 1'}> 第 一 个 Tab 里 的 内 容 </TabPane> 
<TabPane order="1"” tab={'Tab 2'}> 第 二 个 Tab 里 的 内 容 </TabPane> 
<TabPane order="2"” tab={'Tab 3'}> 第 三 个 Tab 里 的 内 容 </TabPane> 
</Tabs> 
); 


expect(tab.find('.tabs-tab')).to.have.length(3); 
expect(tab.find('.tabs-tab')[0].hasClass('tabs-active')).to.be.true; 
}) 


it('changes active tab after click', () => { 
const tab = shallow( 
<Tabs classPrefix={'tabs'} defaultActiveIndex={0} className="ui-tabs"> 
<TabPane order="0"”tab={'Tab 1'}> 第 一 个 Tab 里 的 内 容 </TabPane> 
<TabPane order="1"” tab={'Tab 2'}> 第 二 个 Tab 里 的 内 容 </TabPane> 
<TabPane order="2"” tab={'Tab 3'}> 第 三 个 Tab 里 的 内 容 </TabPane> 
</Tabs> 
); 


tab.find('.tabs-tab')[2].simlate('click'); 
// 第 一 个 标签 取消 选中 ， 第 三 个 标签 被 选中 
expect(tab.find('.tabs-tab')[0].hasClass('tabs-active')).to.be.false; 
expect(tab.find('.tabs-tab')[2].hasClass('tabs-active')).to.be.true; 
}); 
]); 
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Enzyme shallow 演 染 模式 可 以 解决 大 部 分 测试 问题 ， 而 且 性 能 非常 好 。 通 过 类 jQuery 的 API 
来 操作 DOM, 减少 了 很 多 重复 代码 ， 比 Jest 更 加 高 效 。 因 此 , 越 来 越 多 的 项 目 正 在 使 用 Enzyme。 

最 后 ， 为 了 便于 测试 ，React 组 件 应 该 尽 可 能 采用 声明 式 的 写法 。 反 过 来 讲 ， 你 也 可 以 根据 
一 个 组 件 是 否 易 于 测试 来 反 推 代 码 质量 。 一 个 好 的 React 组 件 也 一 定 是 易于 测试 的 。 测 试 可 以 让 
代码 变 得 更 加 健壮 ， 后 期 扩展 也 更 加 有 信心 。 












































2.8.3 自动 化 测试 

现在 是 时 候 把 整个 流程 自动 化 起 来 了 , 你 需要 一 个 持续 集成 服务 器 ( CI ) 来 把 整个 流程 自动 
化 。 如 果 使 用 GitHub 或 Gitlab 来 管理 代码 ， 你 可 以 使 用 Travis CI 或 Circle CI。 

每 当 有 新 的 Commit 提交 或 PR 发 起 后 , CI 就 会 自动 执行 测试 , 我 们 可 以 及 时 看 到 测试 结果 。 

在 后 端 工 程 中 ， 早 就 流传 着 “如 果 这 个 库 没 有 测试 代码 ， 那 谁 敢 用 ”的 话 ， 可 见 测 试 在 现代 
软件 开发 中 扮演 着 越 来 越 重 要 的 角色 , 前 端 引 入 单元 测试 也 是 因为 复杂 客户 端 应 用 的 大 趋势 。 我 
们 不 得 不 对 复杂 的 交互 逻辑 进行 提前 验证 ， 以 保证 在 修改 功能 时 避免 主 功能 上 的 问题 。 









































2.9 组 件 化 实例 : 优化 Tabs 组 件 


经 过 这 一 章 对 React 各 个 部 分 的 深入 介绍 ， 我 们 试 着 用 所 讲 的 知识 对 1.8 节 的 Tabs 组 件 做 一 
次 彻底 的 优化 : 





import React, { Component, PropTypes, cloneElement } from 'react'; 
import ReactDOM from 'react-dom'; 

import EventEmitter from 'events'; 

import classnames from 'classnames'; 

import CSSModules from 'react-css-modules'; 

import { Seq } from 'immutable'; 

import { immutableRenderDecorator } from 'react-immutable-render-mixin'; 
import { Motion, spring } from 'react-motion'; 

import styles from './app.scss'; 


这 次 我 们 引入 更 多 的 库 ， 其 中 包括 Immutable 库 、 配 套 的 PureRender 库 react-immutable- 
render-mixin、 简 化 CSS Modules 的 库 react-css-modules 和 动画 库 React Motion 。 


首先 ， 从 我 们 引入 的 CSS Modules 讲 起 ， 这 里 使 用 react-css-modules 库 。 经 过 webpack 的 配 
置 后 ，Tabs 组 件 就 具备 泻 染 CSS Modules 的 能 力 了 。 对 应 的 样式 文件 最 大 的 变化 就 是 扁平 化 了 : 


.bar { 
position: relative; 
margin-bottom: 16px; 


} 





























.Nav { 
font-size: 14px; 
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&:after, 

&:before { 
display: table; 
content: " "; 


} 


&:after { 
clear: both; 
} 
站 


.tab { 
float: left; 
list-style: none; 
margin-right: 24px; 
padding: 8px 20px; 
text-decoration: none; 
color: #666; 
cursor: pointer; 


} 


.tabActive { 
color: #00C49F; 
cursor: default; 


} 


.paneL { 
display: none; 


: 


.Content { 
display: block; 
} 


.COontentActive { 
display: block; 
} 


.inkBar { 
position: absolute; 
left: 0; 
bottom: 1px; 
box-sizing: border-box; 
height: 2px; 
background-color: #00C49F; 
z-index: 1; 


} 


在 JSX 中 ， 只 要 使 用 styleName prop 来 设置 对 应 的 key 即 可 。 我 们 直接 看 TabPane 组 件 使 用 
CSS Modules 的 例子 : 











@immutableRenderDecorator 
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@CSSModules(styles, { allowMultiple: true }) 
class TabPane extends Component { 
static propTypes = { 
tab: PropTypes.oneOfType([ 
PropTypes.string, 
PropTypes .node, 
]).isRequired, 
order: PropTypes.string.isRequired, 
disable: PropTypes.bool, 
isActive: PropTypes.bool, 


}; 





render() { 
const { className, isActive, children } = this.props; 


const classes = classnames({ 
panel: true, 
contentActive: isActive, 


]); 


return ( 
<div 
role="tabpanel" 
styleName={classes} 
aria-hidden={!isActive}> 
{children} 
</div> 
); 
} 
} 

















此 外 ， 我们 看 到 immutableRenderDecorator 和 CSSModules 是 两 个 高 阶 组 件 。 需 要 说 明 的 是 ， 
对 于 与 组 件 主体 功能 无 关 的 抽象 ， 我 们 一 般 都 用 高 阶 组 件 来 抽象 。 


对 TabPane 的 父 组 件 TabContent 的 改写 ， 也 采用 类 似 的 方式 ; 


QimmutabLeRenderDecorator 
@CSSModules(styles, { allowMultiple: true }) 
class TabContent extends Component { 
static propTypes = { 
panels: PropTypes.object, 
activeIndex: PropTypes.number, 


}; 


getTabPanes() { 
const { activeIndex, panels } = this.props; 


return panels.map((child) => { 
if (!child) { return; } 


const order = parseInt(child.props.order, 10); 
const isActive = activeIndex === order; 


128 第 2 章 漫谈 React 





return React.cloneElement(child, { 
isActive, 
children: child.props.children, 
key: ‘tabpane-${order}, 

]); 


} 


render() { 
const classes = classnames({ 
content: true, 


})); 


return ( 
<div styleName={classes}> 
{this.getTabpanes()} 
</div> 
); 
} 
: 


接着 ,我 们 来 看 TabNav 组 件 ， 一 个 显著 的 更 新 是 对 其 增加 了 动画 效果 ， 即 对 切换 到 当前 选 
中 的 tab 标签 的 下 划 线 做 了 滑动 效果 。 这 里 利用 了 React Motion 库 来 实现 : 


function getOuterWidth(el) { 
return el.offsetWidth; 


























} 


function getOffset(eL) { 
const html = el.ownerDocument.documentElement; 
const box = el.getBoundingClientRect(); 


return { 
top: box.top + Window.pageYOffset - html.clientTop, 
left: box.left + window.pageXOoffset - html.clientLeft, 
}; 
} 


@immutableRenderDecorator 
@CSSModules(styles, { allowMultiple: true }) 
class TabNav extends Component { 
static propTypes = { 
panels: PropTypes.object, 
activeIndex: PropTypes.number, 


}; 


constructor(props) { 
super(props); 


this.state = { 
inkBarWidth: 0， 
inkBarLeft: 0， 
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]; 
} 


componentDidMount() { 
// 计算 激活 tab 的 宽度 和 相对 屏幕 的 左 侧 位 置 
const { activeIndex } = this.props; 
const node = ReactDOM.findDOMNode(this); 
const el = node.querySelectorAll('li')[activeIndex]; 





this.setState({ 
inkBarWidth: getOuterWidth(el), 
inkBarLeft: getOffset(eL) .Left， 
]); 
} 


componentDidUpdate(prevProps) { 
if (prevProps.activeIndex !== this.props.activeIndex) { 
const { activeIndex } = this.props; 
const node = ReactDOM.findDOMNode(this); 
const el = node.querySelectorAll('li')[activeIndex]; 


this.setState({ 
inkBarWidth: getOuterWidth(el), 
inkBarLeft: getoffset(el).left, 
]); 
} 
} 


getTabs() { 
const { panels, activeIndex } = this.props; 


// children 经 过 Immutable 转换 后 ， 需 要 使 用 Immutable API 遍历 
return panels.map((child) => { 
if (!child) { return; } 


const order = parseInt(child.props.order, 10); 


let classes = classnames({ 


tab: true, 

tabActive: activeIndex === order, 

disabled: child.props.disabled, 
]); 


let events = {}; 
if (!child.props.disabled) { 
events = { 
onClick: this.props.onTabClick.bind(this, order), 


}; 

} 

const ref = {}; 

if (activeIndex === order) { 
ref.ref = 'activeTab'; 


} 
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return ( 
<li 
role="tab" 
aria-disabled={child.props.disabled ? 'true' : 'false'} 
aria-selected={activeIndex === order? 'true' : 'false'} 


{...events} 
styleName={classes} 
key={order} 
{...ref} 


{child.props.tab} 


</li> 
); 
}); 
} 
render() { 
const { activeIndex } = this.props; 
const rootClasses = classnames({ 
bar: true, 
]); 
const classes = classnames({ 
nav: true, 
}); 
return ( 
<div styleName={rootClasses} role="tablist"> 
<Motion style={{ Left: spring(this.state.inkBarLeft) }}> 
{({ left }) => <InkBar width={this.state.inkBarWidth} Left={Left} />} 
</Motion> 
<UL styleName={classes}> 
{this.getTabs()} 
</ul> 
</div> 
); 
} 
} 





对 于 这 个 效果 , 我 们 只 是 在 改变 它 的 样式 ， 只 需要 改变 滑动 条 的 横向 距离 即 可 。 但 在 这 里 我 














们 没有 用 Left 属性 ， 而 是 利用 了 CSS 的 transtLate3d 启用 GPU 来 加 速 动画 的 泻 染 效率 : 











@immutableRenderDecorator 
@CSSModules(styles, { allowMultiple: true }) 
class InkBar extends Component { 
static propTypes = { 
left: PropTypes.number, 
width: PropTypes.number, 
}; 
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render() { 
const { left, width } = this.props; 


const classes = classnames({ 
inkBar: true, 


]); 


return ( 
<div styleName={classes} style={{ 
WebkitTransform: ‘translate3d(${left}px, 0, 0).，, 
transform: ‘translate3d(${left}px, 0, 0).， 
width: width, 
}> 
</div> 
); 
} 
} 


最 后 是 Tabs 组 件 的 实现 ， 它 利用 了 Immutable 的 Seq 

















QimmutabLeRenderDecorator 
@CSSModules(styles, { allowMultiple: true }) 
class Tabs extends Component { 
static propTypes = { 
children: PropTypes.oneOfType([ 
PropTypes.arrayOf(PropTypes.node) ， 
PropTypes.node， 
])， 
defaultActiveIndex: PropTypes.number ， 
activeIndex: PropTypes.number ， 
onChange: PropTypes .func， 
}; 


static defauLtProps = { 
onChange: () => {}, 
}; 


constructor(props) { 
super(props); 


this.handleTabClick = this.handleTabClick.bind(this); 
this.immChildren = Seq(currProps.children); 


const currProps = this.props; 


let activeIndex; 

if ('activeIndex' in currProps) { 
activeIndex = CurrProps.activeIndex; 

} else if ('defaultActiveIndex' in currProps) { 
activeIndex = currProps.defaultActiveIndex; 


} 


this.state = { 
activeIndex, 





时 装 了 原来 的 children 数组 : 
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prevIndex: activeIndex, 
}; 
} 


componentWillReceiveprops(nextProps) { 
if ('activeIndex' in nextProps) { 
this.setState({ 
activeIndex: nextProps.activeIndex, 
]); 
} 
} 


handleTabClick(activeIndex) { 
const prevIndex = this.state.activeIndex; 


if (this.state.activeIndex !== activeIndex && 
'defaultActiveIndex' in this.props) { 
this.setState({ 
activeIndex, 
prevIndex ， 


}); 


this.props.onChange({ activeIndex, prevIindex }); 
} 


renderTabNav() { 
return ( 
<TabNav 
key="tabBar" 
onTabClick={this.handleTabClick} 
panels={this.immChildren} 
activeIndex={this.state.activeIndex} 
/> 
); 
} 


renderTabContent() { 
return ( 
<TabContent 
key="tabcontent" 
activeIndex={this.state.activeIndex} 
panels={this.immChildren} 
/> 
); 
} 


render() { 
const { className } = this.props; 
const classes = classnames(className, 'ui-tabs'); 


return ( 
<div className={classes}> 
{this.renderTabNav()} 
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{this.renderTabContent()} 
</div> 
和 
} 

} 

之 前 我 们 也 讲 到 ,对 于 数组 或 对 象 类 型 的 props 而 言 ,优化 的 最 直接 手段 就 是 使 用 Immutable。 
经 过 测试 ，Tabs 组 件 大 大 减少 了 无 意义 的 泻 染 次 数 。 

自 此 ,Tabs 组 件 的 优化 就 告 一 段落 了 。 你 有 没有 发 现 原 Tabs 组 件 是 可 以 设置 classPrefix 以 
表达 主题 ? 在 CSS Modules 中 ， 这 是 怎么 表达 的 呢 ? 这 个 问题 留 给 你 思考 。 




















2.10 “小 结 


本 章 通过 深入 介绍 React 的 概念 及 特性 ， 让 开发 者 从 方方面面 去 熟悉 它 ， 最 终 通 过 优化 Tabs 
组 件 让 开发 者 对 React 组 件 开 发 有 一 个 全 面 的 认识 并 具备 实践 的 能 力 。 随 着 React 的 不 停 发 展 ， 
相关 内 容 一 定 还 会 更 新 ， 但 基本 思路 从 React 诞生 以 来 就 没有 变化 过 。 和 希望 读者 可 以 从 这 些 内 容 
中 举一反三 ， 实 践 出 开发 组 件 的 最 佳 方法 ， 然 后 运用 于 生产 中 ， 并 与 整个 社区 分 享 。 
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通过 前 面 两 章 ， 我 们 系统 学 习 了 React 的 基本 概念 、API、 组 件 的 构建 方法 以 及 高 级 用 法 ， 
然而 这 青 后 的 一 切 显得 那么 神奇 而 又 神秘 ， 它 们 到 底 是 怎么 运转 的 呢 ? 


本 章 会 通过 分 析 React 15.0 的 源码 ， 深 入 Virtual DOM 内 部 的 实现 机 制 和 原理 ， 让 我 们 一 步 
步 揭 开 Virtual DOM 的 神秘 面纱 ， 探 索 其 内 部 的 精彩 世界 ! 


3.1 初探 React 源码 
在 深入 分 析 React 源码 之 前 ， 我 们 先 大 致 了 解 一 下 React 源码 的 组 织 结构 ， 如 图 3-1 所 示 。 


client, event, reconciler, 
server, shared... 
renderers 























children, classic, 
deprecated,moderm... 


图 3-1 React 源码 目录 
在 React 源码 中 ， 每 个 文件 的 命名 风格 属于 字面 与 含义 可 相互 解释 ， 整 体 的 代码 结构 按照 


addons 、isomorphic 、renderers 、shared 、core 、test 进行 组 织 。 
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口 addons :包含 一 系列 的 工具 方法 插件 ,如 PureRenderMixin、CSSTransitionGroup、Fragment、 
LinkedStateMixiin 等 。 

D isomorphic: 包含 一 系列 同 构 方法 。 

口 shared: 包含 一 些 公 用 或 常用 方法 ， 如 Transaction 、CaLLbackQueue 等 。 
D test: 包含 一 些 测试 方法 等 。 

口 core/tests: 包含 一 些 边界 错误 的 测试 用 例 。 

口 renderers: 是 React 代码 的 核心 部 分 , 它 包 含 了 大 部 分 功能 实现 , 此 处 对 其 进行 单独 分 析 。 
renderers 分 为 dom 和 shared 目录 。 











口 dom: 包含 client、server 和 shared。 


ms client: 包含 DOM 操作 方法 (如 ftndDOMNode 、setInnerHTML 、setTextContent 等 ) 以 
及 事件 方法 ,结构 如 图 3-2 所 示 。 这 里 的 事件 方法 主要 是 一 些 非 底 层 的 实用 性 事件 方法 ， 
如 事件 监听 ( ReactEventListener )、 常 用 事件 方法 ( TapEventPlugin、EnterLeave- 
EventPlugin ) 以 及 一 些 合 成 事件 ( SyntheticEvents 等 )。 


renderers 
shared 


reconciler 





























client server shared 


图 3-2” React 下 renderers 源码 目录 








@ Server: 主要 包含 服务 端 演 染 的 实现 和 方法 ( 如 ReactServerRendering、ReactServer- 
RenderingTransaction 等 )。 

m shared: 包含 文本 组 件 ( ReactDOMTextComponent )、 标签 组 件 ( ReactDOMComponent )、 
DOM 属性 操作 ( DOMProperty、DOMPropertyOperations )、CSS 属性 操作 ( CSSProperty、 
CSSpProperty0perations ) 等 。 











口 shared: 包含 event 和 reconciler。 


m event: 包含 一 些 更 为 底层 的 事件 方法 ， 如 事件 插件 中 心 ( EventPluginHub )、 事 件 注册 
( EventPluginRegistry )、 事 件 传播 ( EventPropagators ) 以 及 一 些 事件 通用 方法 。 
React 自 定 义 了 一 套 通 用 事件 的 插件 系统 ， 该 系统 包含 事件 监听 器 、 事 件 发 射 器 、 
件 插件 中 心 、 点 击 事件 、 进 /出 事件 、 简 单 事件 、 合 成 事件 以 及 一 些 事件 方法 ， 如 图 3- 
所 示 。 


























山中 
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SimpleEvent 
Plugin 


EventPluginHub TapEvent 
Plugin 
ReactEvent 
Emitter 
Enter/Leave 
Plugin 


图 3-3 通用 事件 插件 系统 


m reconciler : 称 为 协调 器 ， 它 是 最 为 核心 的 部 分 ， 包 仿 React 中 自 定义 组 件 的 实现 
( ReactCompositeComponent )、 组 件 生命 周期 机 制 、setState 机 制 〈ReactUpdates 、 
ReactUpdateQueue )、DOM diff 算 法 ( ReactMultiChild ) 等 重要 的 特性 方法 。 


那么 ， 为 何 说 reconciler 是 React 最 为 核心 的 部 分 呢 ? 


在 Web 开发 中 ， 要 将 更 新 的 数据 实时 反应 到 UI 上 ， 就 不 可 避免 地 需要 对 DOM 进行 操作 ， 
而 复杂 频繁 的 DOM 操作 通常 是 产生 性 能 瓶颈 的 原因 之 一 。 为 此 ，React 引入 了 Virtual DOM 机 
制 。 毫 不 夸张 地 说 ，VirtualDOM 是 React 的 核心 与 精髓 所 在 ， 而 reconciler 就 是 实现 Virtual DOM 
的 主要 源码 。 

Virtual DOM 实际 上 是 在 浏览 器 端 用 JavaScript 实现 的 一 套 DOM API， 它 之 于 React 就 好 似 
一 个 虚拟 空间 ， 包 括 一 整套 Virtual DOM 模型 、 生 命 周 期 的 维护 和 管理 、 性 能 高 效 的 di 人 算法 和 
将 Virtual DOM 展示 为 原生 DOM 的 Patch 方法 等 。 

基于 React 进行 开发 时 , 所 有 的 DOM 树 都 是 通过 Virtual DOM 构造 的 。React 在 Virtual DOM 
上 实现 了 DOM diff 算法 ， 当 数据 更 新 时 ， 会 通过 diff 寻找 到 需要 变更 的 DOM 节点 ， 并 只 对 变 
化 的 部 分 进行 实际 的 浏览 器 的 DOM 更 新 ， 而 不 是 重新 泻 染 整个 DOM 树 。 

React 也 能 够 实现 Virtual DOM 的 批 处 理 更 新 ， 当 操作 Virtual DOM 时 , 不 会 马上 生成 真实 的 
DOM， 而 是 会 将 一 个 事件 循环 ( event loop ) 内 的 两 次 数据 更 新 进行 合并 ， 这 样 就 使 得 React 能 
够 在 事件 循环 的 结束 之 前 完全 不 用 操作 真实 的 DOM。 例如 ， 多 次 进行 节点 内 容 A 一 B，B 一 A 的 
变化 ，React 会 将 多 次 数据 更 新 合并 为 A 一 B 一 A， 即 A 一 A， 认为 数据 并 没有 更 新 ， 因 此 UI 也 不 
会 发 生 任 何 变化 。 如 果 通 过 手动 控制 ， 这 种 逻辑 通常 是 极其 复杂 的 。 

尽管 每 一 次 都 需要 构造 完整 的 Virtual DOM 树 ， 但 由 于 Virtual DOM 是 JavaScript 对 象 ， 性 










EventProp 
agators 


ReactEvent 
Listener 
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能 极 高 ， 而 对 原生 DOM 进行 操作 的 仅仅 是 di 华 部 分 ， 因 而 能 达到 提高 性 能 的 目的 。 这 样 ， 在 保 
证 性 能 的 同时 ， 开 发 者 将 不 再 需要 关注 某 个 数据 的 变化 如 何 更 新 到 具体 的 DOM 元 素 ， 而 只 需要 
关心 在 任意 数据 状态 下 ， 整 个 界面 是 如 何 泻 染 的 。 

那么 ，React 中 是 如 何 实现 Virtual DOM 机 制 的 呢 ?” 为 众人 所 津津 乐 道 的 diff 算 法 到 底 有 何 
申 秘 之 处 呢 ?” 组 件 的 生命 周期 又 是 如 何 进行 管理 的 呢 ? 


从 下 一 节 开 始 ， 我 们 将 通过 分 析 React 15.0 源码 ， 深 入 研究 Virtual DOM 内 部 的 实现 机 制 及 
原理 。 






































-> 








3.2 ” Virtual DOM 模型 


Virtual DOM 之 于 React, 就 好 比 一 个 虚拟 空间 ，React 的 所 有 工作 几乎 都 是 基于 Virtual DOM 3 
完成 的 。 其 中 , Virtual DOM 模型 负责 Virtual DOM 底层 框架 的 构建 工作 , 它 拥 有 一 整套 的 Virtual 
DOM 标签 ， 并 负责 虚拟 节点 及 其 属性 的 构建 、 更 新 、 删 除 等 工作 。 那 么 ，Virtual DOM 模型 到 
底 是 如 何 构 建 虚 拟 节 点 ， 如 何 更 新 节点 属性 的 呢 ? 
其 实 ， 构建 一 套 简 易 Virtual DOM 模型 并 不 复杂 ， 它 只 需要 具备 一 个 DOM 标签 所 需 的 基本 
元 素 即 可 : 


口 标签 名 
口 节点 属性 ， 包 含 样式 、 属 性 、 事 件 等 
口 子 节 点 
口 标识 id 


示例 代码 如 下 : 


{ 
// 标签 名 
tagName: 'div', 
// 属性 
properties: { 
// 样式 
style: {} 
















































































}, 
A/ 池 这 起 
children: []， 
// 唯一 标识 
key: 1 
} 
Virtual DOM 模型 当然 不 止 于 此 ， 却 也 离 不 开 这 些 基础 元 素 。 现 在 就 让 我 们 揭 下 它 的 神秘 面 


纱 ， 一 探究 竟 吧 


Virtual DOM 中 的 节点 称 为 ReactNode ， 它 分 为 3 种 类 型 ReactElement 、ReactFragment 和 
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ReactText。 其 中 ，ReactElement 又 分 为 ReactComponentElement 和 ReactDOMElement。 
下 面 是 ReactNode 中 不 同类 型 节点 所 需要 的 基础 元 素 : 


type ReactNode = ReactElement | ReactFragment | ReactText; 
type ReactElement = ReactComponentELement | ReactDOMELement; 


type ReactDOMELement = { 
type : string, 
props : { 
children : ReactNodeList， 
CLassName : string， 
etc 


key : string | boolean | number | null, 


ref : string | null 


type ReactComponentELement<TProps> = { 
type : ReactClass<TProps>, 
props : TProps, 
key : string | boolean | number | null, 
ref : string | null 


}; 

type ReactFragment = Array<ReactNode | ReactEmpty>; 
type ReactNodeList = ReactNode | ReactEmpty; 

type ReactText = string | number; 


type ReactEmpty = null | undefined | boolean; 


那么 ，Virtual DOM 模型 是 如 何 根据 这 些 节点 类 型 来 创建 元 素 的 呢 ? 





3.2.1 创建 React 元 素 


在 1.2 节 里 ,我 们 介绍 过 JSX 的 语法 ， 现 在 先 来 回顾 下 它 的 用 法 。 下 面 是 一 段 JSX 与 编译 后 
的 JavaScript: 























const Nav, Profile; 


// 输入 (JSX) : 


const app = <Nav color="blue"><Profile>click</Profile></Nav>; 


// 输出 (JavaScript) : 

const app = React.createElement( 
Nav， 
{color:"blue"}, 
React.createElement(Profile, null, "click") 


和 
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通过 JSX 创建 的 虚拟 元 素 最 终 会 被 编译 成 调用 React 的 createElement 方法 。 那 么 
createElement 方法 到 底 做 了 什么 ， 它 的 奥秘 是 什么 呢 ? 我 们 来 解读 相关 源码 (源码 路 径 : 


/v15.0.0/src/isomorphic/classic/element/ReactElement.js ): 

















// createElement 只 是 做 了 简单 的 参数 修正 ， 返 回 一 个 ReactElement 实例 对 象 ， 
// 也 就 是 虚拟 元 素 的 实例 
ReactELement.createELement = function(type, config, children) { 

// 初始 化 参数 

var propName; 

var props = {}; 

var key = null; 

var ref = null; 

var self = null; 

var source = null; 





// 如 果 存 在 config， 则 提取 里 面 的 内 容 
if (config != nuLL) { 
ref = config.ref === undefined ? nuLL : config.ref; 
key = config.key === Undefined ? null : '' + config.key; 
self = config. seLf === undefined ? null : config. self; 
source = Config. source === Undefined ? nuLL : config. _source; 
// 复制 config 里 的 内 容 到 props (如 id 和 className 等 ) 
for (propName in config) { 
if (config.hasOwnProperty(propName) && 
!RESERVED_PROPS .hasOwnProperty(propName)) { 
props[propName] = config[propName]; 
} 
} 
} 


// 处 理 children， 全 部 挂 载 到 props 的 children 属性 上 。 如 果 只 有 一 个 参数 ， 直 接 赋值 给 chiLdren， 
// 否则 做 合并 处 理 
var childrenLength = arguments.Length - 2; 
if (childrenLength === 1) { 
props.children = children; 
} else if (childrenLength > 1) { 
var childArray = Array(childrenLength); 
for (var i = 0; i < childrenLength; i++) { 
childArray[i] = arguments[i + 2]; 
} 
props.children = childArray; 
} 


// 如 果 某 个 prop 为 空 且 存在 默认 的 prop， 则 将 默认 prop 赋 给 当前 的 prop 
if (type && type.defauLtProps) { 
var defauLtProps = type.defaultProps; 
for (propName in defauLtProps) { 
if (typeof props[propName] === 'undefined') { 
props[propName] = defaultProps[propName]; 
} 
} 
} 
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// 返回 一 个 ReactELement 实例 对 象 


return ReactElement(type, key, ref, self, source, ReactCurrentOwner.current, props); 


}; 

















Virtual DOM 模型 通过 createElement 创建 虚拟 元 素 ， 那 又 是 如 何 创 建 组 件 的 呢 ? 


3.2.2 ”初始 化 组 件 入 口 

















当 使 用 React 创建 组 件 时 ， 首 先 会 调用 instantiateReactComponent， 这 是 初始 化 组 件 的 人口 

















函数 ， 它 通过 判断 node 类 





tiateReactComponent ) 。 


口 当 node 类 型 为 对 象 时 ， 即 是 











InstanceForText(node)。 


口 如 果 是 其 他 情况 ， 则 不 作 处 到 
































型 来 区 分 不 同 组 件 的 入口 。 
口 当 node 为 空 时 , 说 明 node 不 存在 , 则 初始 化 空 组 件 ReactEmptyComponent .create(instan- 


DOM 标签 组 件 或 自 定 义 组 件 ， 那 么 如 果 element 类 型 为 字 
符 串 时 ， 则 初始 化 DOM 标签 组 件 ReactNativeComponent .createInternaLComponent 
(etLement) ， 否 则 初始 化 自 定 义 组 件 ReactCompositeComponentWrapper()。 





昌 
Eo 





instantiateReactComponent 国 数 关系 如 图 3-4 所 示 。 


basic element 


custom element 


图 3-4 





instantiateReactComponent 方 法 的 源码 如 下 (源码 路 径 : 


ReactDOMText- 
Component 


ReactDOM- 
Component 


instantiateReactComponent 


ReactComposite- 


Component 


ReactEmpty- 
Component 





instantiateReactComponent 子 数 关系 


reconciler/instantiateReactComponent.js ): 


口 当 node 类 型 为 字符 串 或 数字 时 ， 则 初始 化 文本 组 件 ReactNativeComponent.create 


/v15.0.0/src/renderers/shared/ 
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// 初始 化 组 件 入 口 
function instantiateReactComponent(node, parentCompositeType) { 
var instance; 


// 空 组 件 (ReactEmptyComponent) 
if (node === null || node === false) { 
instance = ReactEmptyComponent.create(instantiateReactComponent); 


} 


if (typeof node === 'object') { 
var element = node; 
if (typeof element.type === 'string') { 
// DOM 标 签 (ReactDOMComponent ) 
instance = ReactNativeComponent.createInternalComponent(element); 
} else if (isInternaLComponentType(eLement.type)) { 
// 不 是 字符 囊 表 示 的 自 定义 组 件 暂 无 法 使 用 ， 此 处 将 不 做 组 件 初始 化 操作 
instance = new element.type(element); 
} else{ 
// 自 定义 组 件 (ReactCompositeComponent) 
instance = new ReactCompositeComponentWrapper(); 
} 
} pr if (typeof node === 'string' || typeof node === 'number ') { 
字符 串 或 数字 (ReactTextComponent) 
A A = ReactNativeComponent.createInstanceForText(node); 
} else { 
// 不 做 处 理 
} 





// 设置 实例 
instance.construct(node); 

// 初始 化 参数 
instance._mountIndex = 0; 
instance._mountImage = null; 


return instance; 


3.2.3 文本 组 件 


当 node 类 型 为 文本 节点 时 是 不 算 Virtual DOM 元 素 的 , 但 React 为 了 保持 泻 染 的 一 致 性 ， 将 
其 封装 为 文本 组 件 ReactDOMTextComponent。 

















计 








在 执行 mountComponent 方法 时 , ReactDOMTextComponent 通过 transaction.useCreateElement 
判断 该 文本 是 否 是 通过 createELement 0 如 果 是 , 则 为 该 节点 创建 相应 的 标签 和 标 
识 domID， 这 样 每 个 文本 市 点 也 能 与 其 他 React 节点 一 样 拥 有 自己 的 唯一 标识 ， 同 时 也 拥有 了 
Virtual DOM diff 的 权利 ,但 如 果 不 是 通过 createElement 创建 的 文本 ,React 将 不 再 为 其 创建 <span> 
和 domID 标识 ， 而 是 直接 返回 文本 内 容 。 


不 再 为 裸露 的 文本 内 容 包 于 <span> 标签 ， 是 React 15.0 版 本 的 更 新 点 之 一 。 此 前 ，React 为 
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裸露 的 文本 内 容 包 右 上 <span> 标签 ， 其 实 并 没有 产生 任何 作用 ， 反 而 增加 了 不 必要 的 标签 ， 因 
此 React 15.0 版 本 将 去 掉 这 些 操 作 。 


在 执行 receiveComponent 方法 时 ， 可 以 通过 DoMChildrenOperations.replaceDelimitedText 
(commentNodes[0]，commentNodes[1]，nextStringText) 来 更 新 文本 内 容 。 


ReactTextComponent 关系 如 图 3-5 所 示 。 




















ReactTextComponentFactory 


mountComponent construct receiveComponent 





transaction.useCreateElement 


Se 


openingComment + stringText + closingComment escapedText 


图 3-5” ReactTextComponent 关系 


ReactDOMTextComponent 的 源码 ( 源码 路 径 : /v15.0.0/src/renderers/dom/shared/ReactDOM- 
TextComponent.js ) 如 下 : 


// 创建 文本 组 件 ， 这 是 ReactText， 并 不 是 ReactElement 
var ReactDOMTextComponent = function(text) { 

// 保存 当前 的 字符 串 

this._currentElement = text; 

this._stringText = '' + text; 


// ReactDOMComponentTree 需要 使 用 的 参数 
this. nativeNode = null; 
this._nativeparent = null; 


// 属性 

this._domID = null; 

this. mountIndex = 0; 
this._closingComment = null; 
this._commentNodes = null; 


}; 


Object.assign(ReactDOMTextComponent.prototype, { 
mountComponent: function(transaction, nativeparent, nativeContainerInfo, context) { 
var domID = nativeContainerInfo. idCounter+t+; 
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}, 


var openingValuyue = ' react-text: 
var closingValue = ' /react-text '; 
this._domID = domID; 

this._nativeparent = nativeparent; 


和 和 这 


+ domID + 


// 如 果 使 用 createElement 创建 文本 标签 ， 则 该 文本 会 带 上 标签 和 domID 
if (transaction.useCreateElement) { 
var ownerDocument = nativeContainerInfo._ ownerDocument; 
var openingComment = ownerDocument.createComment(openingValue); 
var closingComment = ownerDocument.createComment(closingValue); 
var lazyTree = DOMLazyTree(ownerDocument.createDocumentFragment()); 
// 开始 标签 
DOMLazyTree.queueChild(lazyTree, DOMLazyTree(openingComment)); 
// 如 果 是 文本 类 型 ， 则 创建 文本 节点 
if (this._stringText) { 
DOMLazyTree.queueChild(lazyTree, DOMLazyTree(ownerDocument.createTextNode 
(this._stringText))); 
} 
// 结束 标签 
DOMLazyTree.queueChild(lazyTree, DOMLazyTree(closingComment)); 
ReactDOMComponentTree.precacheNode(this, openingComment); 
this._closingComment = closingComment; 
return lazyTree; 
} else { 
var escapedText = escapeTextContentForBrowser(this._stringText); 
// 静态 页 面 下 直接 返回 文本 
if (transaction.renderToStaticMarkup) { 
return escapedText; 
} 
// 如 果 不 是 通过 createElement 创建 的 文本 ， 则 将 标签 和 属性 注释 掉 ， 直 接 返回 文本 内 容 
return ( 
'<!--' + openingvaLue + '-->' + escapedText + 
'<!--' + ClosingValye + '-->" 
); 


// 更 新 文本 内 容 


receiveComponent: function(nextComponent, transaction) { 


if (nextText !== this._ currentElement) { 
this._currentElement = nextText; 
var nextStringText = '' + nextText; 
if (nextStringText !== this._stringText) { 


this._stringText = nextStringText; 
var commentNodes = this.getNativeNode(); 


DOMChildrenOperations.replaceDelimitedText(commentNodes[0], commentNodes[1], 
nextStringText); 
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3.2.4 ”DOM 标签 组 件 


Virtual DOM 模型 涵盖 了 几乎 所 有 的 原生 DOM 标签 ， 如 <div>、<p>、<span> 等 。 当 开发 者 
使 用 React 时 ， 此 时 的 <div> 并 不 是 原生 <div> 标签 ， 它 其 实 是 React 生成 的 Virtual DOM 对 象 ， 
只 不 过 标签 名 称 相同 罢了 。React 的 大 部 分 工作 都 是 在 Virtual DOM 中 完成 的 , 对 于 原生 DOM 而 
言 ，Virtual DOM 就 如 同一 个 隔离 的 沙 盒 ， 因 此 React 的 处 理 并 不 是 直接 操作 和 污染 原生 DOM ， 
这 样 不 仅 保持 了 性 能 上 的 高 效 和 稳定 ， 而 且 降 低 了 直接 操作 原生 DOM 而 导致 错误 的 风险 。 

ReactDOMComponent 针对 Virtual DOM 标签 的 处 理 主要 分 为 以 下 两 个 部 分 : 


口 属性 的 更 新 ， 包 括 更 新 样式 、 更 新 属性 、 处 理事 件 等 ; 
口 子 节点 的 更 新 ， 包 括 更 新 内 容 、 更 新 子 节 点 ， 此 部 分 涉及 di 企 算法 。 
1. 更 新 属性 


当 执 行 mountComponent 方法 时 ，ReactDOMComponent 首先 会 生成 标记 和 标签 ， 通 过 this. 
createOpenTagMarkupAndPutListeners(transaction) 来 处 理 DOM 节点 的 属性 和 事件 。 
口 如 果 存 在 事件 ， 则 针对 当前 的 节点 添加 事件 代理 ， 即 调用 enqueuePutListener(this， 
propKey, propValue, transaction)。 
口 如 果 存 在 样式 ， 首 先 会 对 样式 进行 合并 操作 0bject.assign({}, props.style)， 然 后 通过 
CSSPropertyOperations.createMarkupForStyles(propValue，this) 创建 样式 。 
口 通过 DOMPropertyOperations.createMarkupForProperty(propKey，propValue) 创建 属性 。 
口 通过 DoMPropertyOperations.createMarkupForID(this._ domID) 创建 唯一 标识 。 


_create0penTagMarkupAndPutListeners 方法 的 源码 如 下 (源码 路 径 : /v15.0.0/src/renderers/ 
dom/shared/ReactDOMComponent.js ): 


























PT 









































_createOpenTagMarkupAndPutListeners: function(transaction, props) { 
var ret = '<' + this._currentElement.type; 
// 拼凑 出 属性 
for (var propKey in props) { 
var propVvaLue = props[propKey]; 


if (registrationNameModules.hasOwnProperty(propKey)) { 
// 针对 当前 的 节点 添加 事件 代理 
if (propValue) { 
enqueuePutListener(this, propKey, propValue, transaction); 
} 
} else { 
if (propKey === STYLE) { 
if (propValue) { 
// 合并 样式 
propValue = this. previousStyleCopy = Object.assign({}, props.style); 
} 


propValue = CSSPropertyOperations.createMarkupForStyles(propValue, this); 
} 
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// 创建 属性 标识 

var markup = null; 

if (this. tag != null && isCustomComponent(this. tag, props)) { 
markup = DOMPropertyOperations.createMarkupForProperty(propKey, propValuyue); 

} 

if (markup) { 
ret += " 

} 

二 
3} 


+ markup; 


// 对 于 静态 页 面 ， 不 需要 设置 react-id,， 这样 可 以 节省 大 量 字 节 
if (transaction.renderToStaticMarkup) { 
return ret; 


} 





// 设置 react-id 
if (!this. nativeparent) { 
ret += ' ' + DOMPropertyOperations.createMarkupForRoot(); 


} 


ret += 


+ DOMPropertyOperations.createMarkupForID(this._domID); 


return ret; 


降 
冲 


去 除 data-reactid 是 React 15.0 的 更 新 点 之 一 。 众 所 周知 ，React 泻 染 后 的 每 个 DOM 节 
点 都 会 添加 data-reactid 属性 。 这 个 作为 DOM 节点 的 唯一 标识 而 存在 的 字符 串 ， 不 仅 
对 用 户 毫 无 用 处 ， 而 且 还 会 存在 一 定 的 性 能 影响 。 因 为 DOM J 点 | 
data-reactid 属性 也 会 进行 更 新 ， 而 更 新 DOM 节点 属性 是 需要 部 分 性 能 消耗 的 。 其 

早 有 开发 者 向 React 官方 提 过 问题 ， i 0 React 15.0 
版 本 上 实现 了 。 据 官方 宣称 ， 去 除 data-reactid 使 得 React 性 能 有 了 10% 的 提升 。 


当 执 行 receiveComponent 方 法 时 ，ReactDOMComponent 会 通过 this.updateComponent 
(transaction，prevElement，nextElement，context) 来 更 新 DOM 节点 属性 。 


先是 删除 不 需要 的 旧 属 性 。 如 果 不 需 要 旧 样 式 , 则 遍历 旧 样 式 集合 ， 并 对 每 个 样式 进行 置 空 
删除 ， 如 果 不 需 要 事件 ， 则 将 其 事件 监听 的 属性 去 掉 ， 即 针对 当前 的 节点 取消 事件 代理 
deleteListener(this，propKey) ; 如 果 旧 属性 不 在 新 属性 集合 里 时 ， 则 需要 删除 旧 属 性 
DOMPropertyOperations.deleteValueForProperty(getNode(this), propKey)。 

再 是 更 新 新 属性 。 如 果 存 在 新 样式 ， 则 将 新 样式 进行 合并 0bject.assign({}, nextProp); 如 
果 在 旧 样 式 中 但 不 在 新 样式 中 ， 则 清除 该 样式 ; 如 果 既 在 旧 样 式 中 也 在 新 样式 中 ， 且 不 相同 ， 则 
更 新 该 样式 styleUpdates[styleName] = nextProp[styleName]; 如 果 在 新 样式 中 ， 但 不 在 旧 样 式 
中 ， 则 直接 更 新 为 新 样式 styleUpdates = nextProp; 如 果 存 在 事件 更 新 ， 则 添加 事件 监听 的 
性 enqueuePutListener(this，, propKey, nextProp，transaction); 如 果 存 在 新 属性 ， 则 添加 新 
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生 ， 或 者 更 新 旧 的 同名 属性 DoMProperty0perations.setVaLueForAttribute(node，propKey， 


nextpProp ) 。 


至 此 ，ReactDOMComponent 完成 了 DOM 节点 属性 更 新 的 操作 ， 相 关 代码 如 下 : 











_updateDOMProperties: function(lastProps, nextProps, transaction) { 


var propKey; 
var styleName; 
var styleUpdates; 


// 当 一 个 旧 的 属性 不 在 新 的 属性 集合 里 时 ， 需 要 删除 
for (propKey in LastProps) { 

// 如 果 新 属性 里 有 ， 或 者 propKey 是 在 原型 上 的 则 直接 跳 过 ， 这 样 剩 下 的 都 是 不 在 新 属性 集合 里 的 ， 

// 需要 删除 

if (nextProps.hasOwnProperty(propKey) || !LastProps.hasOwnProperty(propKey) || LastProps[propKey] 
== nuLL) { 
continue; 

} 

// 从 DOM 上 删除 不 需要 的 样式 

if (propKey === STYLE) { 
var lastStyle = this. previousStyleCopy; 
for (styleName in lastStyle) { 

if (lastStyle.hasOwnProperty(styleName)) { 
styleUpdates = styLeUpdates || {}; 
styleUpdates[styleName] = "'; 
} 
} 
this._previousStyleCopy = null; 

} else if (registrationNameModules.hasOwnProperty(propKey)) { 

if (lastProps[propKey]) { 

// 这 里 的 事件 监听 的 属性 需要 去 掉 监 听 ， 针 对 当前 的 节点 取消 事件 代理 
detLeteListener(this，propKey); 
} 

} else if (DOMProperty.isStandardName[propKey] || DOMProperty.isCustomAttribute(propKey)) { 
// 从 DOM 上 删除 不 需要 的 属性 
DOMPropertyOperations.deleteValueForProperty(getNode(this), propKey); 

); 

} 

} 


// 对 于 新 的 属性 ， 需 要 写 到 DOM 节点 上 
for (propKey in nextProps) { 
var nextProp = nextProps[propKey]; 
var LastProp 
propKey === STYLE ? this. previousStyleCopy : 
lastProps != nuLL ? lastProps[propKey] : undefined; 
// 不 在 新 属性 中 ， 或 与 昌 属 性 相同 ， 则 跳 过 
if (!nextProps.hasOwnProperty(propKey) || nextProp === lastProp || nextProp == null && LastpProp 
== null) { 
continue; 


} 
// 在 DOM 上 写 入 新 样式 (更 新 样式 ) 
if (propKey === STYLE) { 
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if (nextProp) { 
nextProp = this._ previousStyleCopy = Object.assign({}, nextProp); 
} 
if (LastProp) { 
// 在 旧 样 式 中 且 不 在 新 样式 中 ， 清 除 该 样式 
for (styleName in LastProp) { 
if (lastProp.hasOwnProperty(styleName) && (!nextpProp 
|| !nextProp.hasOwnProperty(styleName))) { 
styleUpdates = styleUpdates || {}; 
styLeUpdates[styLeName] = "'; 
} 
} 
// 既 在 旧 样 式 中 也 在 新 样式 中 ， 且 不 相同 ， 更 新 该 样式 
for (styleName in nextProp) { 
if (nextProp.hasOwnProperty(styleName) && LastProp[styLeName] !== nextProp[styLeName]) { 
styleUpdates = styleUpdates || {}; Ee 
styLeUpdates[styLeName] = nextProp[styleName]; 
} 
} 
} elsef{ 
// 不 存在 旧 样 式 ， 直 接 写 入 新 样式 
styLeUpdates = nextProp; 
} 
} else if (registrationNameModules.hasOwnProperty(propKey)) { 
if (nextProp) { 
// 添加 事件 监听 的 属性 
enqueuePutListener(this, propKey, nextProp, transaction); 
} else{ 
deleteListener(this, propKey); 
} 
// 添加 新 的 属性 ， 或 者 是 更 新 旧 的 同名 属性 
} else if (isCustomComponent(this. tag, nextProps)) { 
if (!RESERVED_PROPS.hasOwnProperty(propKey)) { 
// setValueForAttribute 更 新 属性 
DOMPropertyOperations.setValueForAttribute(getNode(this), propKey, nextProp); 
} 
} else if (DOMProperty.properties[propKey] || DOMProperty.isCustomAttribute(propKey)) { 
var node = getNode(this); 
if (nextProp != null) { 
DOMPropertyOperations.setValueForProperty(node, propKey, nextProp); 
} else{ 
// 如 果 更 新 为 null 或 undefined， 则 执行 删除 属性 操作 
DOMPropertyOperations.deleteValueForProperty(node, propKey); 
} 
// 如 果 styleUpdates 不 为 空 ， 则 设置 新 样式 
if (styleUpdates) { 
CSSPropertyOperations.setValuyeForStyles(getNode(this), styleUpdates, this); 
上 
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2. 更 新 子 节点 
当 执 行 mountComponent 方法 时 ，ReactDOMComponent 会 通过 this. createContentMarkup 
(transaction，props，context) 来 处 理 DOM 节点 的 内 容 。 


首先 ， 获 取 节 点 内 容 props.dangerouslySetInnerHTML。 如 果 存 在 子 节点 ， 则 通过 this. 
mountChildren(childrenToUse，transaction，context) 对 子 节 点 进行 初始 化 泻 染 : 








_CreateContentMarkup: function(transaction, props, context) { 


var ret = 2 


// 获取 子 节点 泻 染 出 的 内 容 
var innerHTML = props.dangerouslySetInnerHTML; 


if (innerHTML != null) { 
if (innerHTML.__html != null) { 
ret = innerHTML.__html; 


} 

} elsef{ 
var contentToUse = CONTENT_TYPES[typeof props.children] ? props.children : null; 
var childrenToUse = contentToUse != nuLL ? null : props.children; 


if (contentToUse != null) { 

ret = escapeTextContentForBrowser(contentToUse); 
} else if (childrenToUse != null) { 

// 对 子 节点 进行 初始 化 演 染 


var mountImages = this.mountChildren(childrenToUse, transaction, context); 


ret = mountImages.join(''); 
3 
} 
// 是 否 需 要 换行 
if (newlineEatingTags[this. tag] && ret.charAt(0) === '\n') { 
return '\n' + ret; 
} else 并 
return ret; 
} 
} 
当 执 行 receiveComponent 方法 时 ，ReactDOMComponent 会 通过 this._updateDOMChildren 


(LastProps，nextProps，transactton，context) 来 更 新 DOM 内 容 和 子 节 点 。 

先是 删除 不 需要 的 子 节点 和 内 容 。 如 果 旧 节点 存在 , 而 新 节点 不 存在 , 说 明 当 前 节点 在 更 新 
后 被 删除 ， 此 时 执行 方法 this.updateChildren(null，transaction,，context); 如 果 旧 的 内 容 存 
在 ， 而 新 的 内 容 不 存在 ， 说 明 当 前 内 容 在 更 新 后 被 删除 ， 此 时 执行 方法 this.updateText- 
Content('')。 

再 是 更 新 子 节点 和 内 容 。 如 果 新 子 节点 存在 ， 则 更 新 其 子 节点 ， 此 时 执行 方法 this.update- 
Children(nextChildren, transaction, context); 如 果 新 的 内 容 存 在 ， 则 更 新 内 容 ， 此 时 执行 方 
法 this.updateTextContent('' + nextContent)。 
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至 此 ，ReactDOMComponent 完成 了 DOM 子 节点 和 内 容 的 更 新 操作 ， 相 关 代 码 如 下 : 


_updateDOMChildren: function(lastProps, nextProps, transaction, context) { 
// 初始 化 
var LastContent = CONTENT_TYPES[typeof LastProps.chiLdren] ? LastProps.chiLdren : null; 
var nextContent = CONTENT_TYPES[typeof nextProps.chiLdren] ? nextProps.chiLdren : null; 
var lastHtml = LastProps.dangerousLySetInnerHTML && lastProps.dangerouslySetInnerHTML.__html; 
var nextHtml = nextProps.dangerousLySetInnerHTML && nextProps.dangerouslySetInnerHTML.__html; 


var lastChildren = lastContent != null ? null : lastProps.children; 


var nextChildren = nextContent != null ? nuLL : nextProps.children; 
var LastHasContentOrHtmL = LastContent != null || LastHtmL != null; 
var nextHasContentOrHtmL = nextContent != null || nextHtmL != null; 


if (LastChiLdren != null && nextChildren == null) { 
// 旧 节 点 存在 ， 而 新 节点 不 存在 ， 说 明 当 前 节点 在 更 新 后 被 删除 了 
this.updateChildren(null, transaction, context); 
} else if (lastHasContentOrHtml && !nextHasContentOrHtmL) { 
// 说 明 当 前 内 容 在 更 新 后 被 删除 了 
this.updateTextContent(''); 





} 
// 新 节点 存在 
if (nextContent != nuLL) { 
// 更 新 内 容 
if (LastContent !== nextContent) { 
this.updateTextContent('' + nextContent); 
} 


} else if (nextHtmL != null) { 
// 更 新 属性 标识 
if (lastHtml !== nextHtmL) { 
this.updateMarkup('' + nextHtml); 
} 
} else if (nextChildren != null) { 
// 更 新 子 节点 
this.updateChildren(nextChildren, transaction, context); 
} 
} 


汪 纯 截 组 件 时 ReactDOMComponent 会 进行 一 系列 的 操作 ， 如 缉 载 子 节点 、 清 除 事件 监听 、 
清空 标识 





unmountComponent: function(safely) { 
this.unmountChildren(safely); 
ReactDOMComponentTree.uncacheNode(this); 
EventPluginHub.deleteAllListeners(this); 
ReactComponentBrowserEnvironment.unmountIDFromEnvironment(this._rootNodeID); 
this._rootNodeID = null; 
this. domID = null; 
this. wrapperState = null; 

} 


ReactDOMComponent 关系 如 图 3-6 所 示 。 
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ReactDOMComponent 


mountComponent receiveComponent updateComponent 


_createOpenTagMarkupAnd- 


DUELLStenere _updateDOMProperties 


_CreateContentMarkup _updateDOMChildren 





图 3-6 ReactDOMComponent 关 系 


其 中 ，updateChildren 为 diff 中 的 内 容 ， 请 移 步 至 3.5 节 。 





3.2.5” 自 定义 组 件 


ReactCompositeComponent 自 定义 组 件 实现 了 一 整套 React 生命 周期 和 setState 机 制 ， 因 此 自 
定义 组 件 是 在 生命 周期 的 环境 中 进行 更 新 属性 、 内 容 和 子 节点 的 操作 。 这 些 更 新 操作 与 
ReactDOMComponent 的 操作 类 似 ， 在 此 就 不 歼 述 了 。 


如 果 对 React 生命 周期 机 制 不 了 解 ， 下 一 节 就 可 以 让 你 深入 了 解 生 命 周期 的 管理 艺术 。 
ReactCompositeComponent 关系 如 图 3-7 所 示 。 









































mountComponent unmountComponent receiveComponent updateComponent 


construct ReactCompositeComponent createClass 


performUpdateIf- _updateRendered- 


performInitialMount Necessary Component 


_processPendingState 





图 3-7 ReactCompositeComponent 关系 
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3.3 生命 周期 的 管理 艺术 


对 于 React 组 件 ， 生 命 周期 是 它 的 核心 概念 之 一 。 在 1.5 节 中 ,我 们 已 经 大 概 了 解 了 生命 周 
期 的 概念 及 用 法 ， 本 节 将 深入 源码 来 剖析 React 生命 周期 的 管理 艺术 。 


React 的 主要 思想 是 通过 构建 可 复 用 组 件 来 构建 用 户 界 面 。 所 谓 组 件 ， 其 实 就 是 有 限 状 态 机 
( FSM )， 通 过 状态 泻 染 对 应 的 界面 ,， 且 每 个 组 件 都 有 自己 的 生命 周期 ， 它 规定 了 组 件 的 状态 和 方 
法 需要 在 哪个 阶段 改变 和 执行 。 

有 限 状 态 机 , 表示 有 限 个 状态 以 及 在 这 些 状态 之 间 的 转移 和 动作 等 行为 的 模型 。 一般 通 过 状 
态 、 事 件 、 转 换 和 动作 来 描述 有 限 状 态 机 。 图 3-8 是 描述 组 合 锁 状 态 机 的 模型 图 , 包括 5 个 状态 、 
5 个 状态 自转 换 、6 个 状态 间 转 换 和 1 个 复位 RESET 转换 到 状态 s1。 状 态 机 能 够 记 住 目前 所 处 
的 状态 ,可 以 根据 当前 的 状态 做 出 相应 的 决策 , 并 且 可 以 在 进入 不 同 的 状态 时 做 不 同 的 操作 。 状 
态 机 将 复杂 的 关系 简单 化 ， 利 用 这 种 自然 而 直观 的 方式 可 以 让 代码 更 容易 理解 。 
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图 3-8 ”状态 机 模型 


React 正 是 利用 这 一 概念 ， 通 过 管理 状态 来 实现 对 组 件 的 管理 。 例 如 ， 某 个 组 件 有 显示 和 隐 
藏 两 个 状态 ， 通 常会 设计 两 个 方法 show() 和 hide() 来 实现 切换 ， 而 React 只 需要 设置 状态 
setState({f showed: true/false }) 即 可 实现 。 同 时 ，React 还 引入 了 组 件 的 生命 周期 这 个 概念 。 
通过 它 ， 就 可 以 实现 组 件 的 状态 机 控制 ， 从 而 达到 “生命 周期 一 状态 一 组 件 ” 的 和 谐 画面 。 

虽然 组 件 、 状 态 机 、 生 命 周 期 这 三 者 都 不 是 React 独创 的 ， 但 Web Components 标准 与 其 中 
的 自 定义 组 件 的 生命 周期 的 概念 相似 。 就 目前 而 言 ，React 是 将 这 几 种 概念 结合 得 相对 清晰 、 流 
畅 的 View 实现 。 


















































152 第 3 章 解读 React 源码 





3.3.1 初探 React 生命 周期 


在 自 定义 React 组 件 时 ， 我 们 会 根据 需要 在 组 件 生 命 周期 的 不 同 阶段 实现 不 同 的 逻辑 。 为 了 
查看 组 件 生命 周期 的 执行 顺序 ， 推 荐 使 用 react-lifecycle mixin。 将 此 mixin 添加 到 需要 观察 的 组 
件 中 ， 当 任何 生命 周期 方法 被 调用 时 ， 就 能 在 控制 台 观 察 到 对 应 的 生命 周期 的 调用 时 状态 。 

通过 反复 试验 ， 我 们 得 到 了 组 件 的 生命 周期 在 不 同 状态 下 的 执行 顺序 。 

口 当 首 次 挂 载 组 件 时 , 按 顺序 执行 getDefauLtProps、getInitiaLState 、componentNLLLMount、 

render 和 componentDidMount。 

口 当 御 载 组 件 时 ， 执 行 componentWillUnmount。 

口 当 重 新 挂 载 组 件 时 ， 此 时 按 顺 序 执 行 getInitialstate、componentWillMount、render 和 

componentDidMount ， 但 并 不 执行 getDefaultProps。 

口 当 再 次 泻 染 组 件 时 , 组 件 接受 到 更 新 状态 , 此 时 按 顺序 执行 componentWillReceiveProps、 
shouldComponentUpdate 、componentWillUpdate 、render 和 componentDidUpdate。 

当 使 用 ES6 classes 构建 React 组 件 时 ，static defaultProps = {} 其 实 就 是 调用 内 部 的 getDe- 
faultProps 方法 ，constructor 中 的 this.state = {} 其 实 就 是 调用 内 部 的 getInitialstate 方法 。 
因此 ， 源 码 解读 的 部 分 与 用 createClass 方法 构建 组 件 一 样 。 





































































































生命 周期 的 执行 顺序 如 图 3-9 所 示 。 


First Render Unmount 





图 3-9 生命 周期 的 执行 顺序 


那么 ， 为 何 React 会 按 上 述 顺序 执行 生命 周期 ? 为 何 多 次 泻 染 时 ，React 会 执行 生命 周期 的 
不 同 阶段 ? 为 何 getDefaultProps 只 执行 了 一 次 ? 




















3.3.2 ”详解 React 生命 周期 


自 定义 组 件 ( ReactCompositeComponent ) 的 生命 周期 主要 通过 3 个 阶段 进行 管理 一 一 
MOUNTING 、RECEIVE_PROPS 和 UNMOUNTING， 它 们 负责 通知 组 件 当 前 所 处 的 阶段 ， 应 该 
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执行 生命 周期 中 的 哪个 步骤。 这 3 个 阶段 对 应 3 种 方法 ,分 别 为 :mountComponent ,updateComponent 
和 unmountComponent， 每 个 方法 都 提供 了 几 种 处 理 方 法 ， 其 中 带 will 前 级 的 方法 在 进入 状态 之 
前 调用 ， 带 did 前 级 的 方法 在 进入 状态 之 后 调用 。3 个 阶段 共 包括 $ 种 处 理 方法 ， 还 有 两 种 特殊 
状态 的 处 理 方法 。 




















生命 周期 的 3 个 阶段 如 图 3-10 所 示 。 


UN UN 
MOUNTED MOUNTED MOUNTED 
rr— 一 








MOUNTING RECEIVE_ | | UNMOUN- 
PROPS TING 


图 3-10 生命 周期 的 3 个 阶段 
1. 使 用 createClass 创建 自 定义 组 件 
createClass 是 创建 自 定义 组 件 的 入口 方法 ， 负 责 管理 生命 周期 中 的 getDefaultProps。 该 方 
法 在 整个 生命 周期 中 只 执行 一 次 ， 这 样 所 有 实例 初始 化 的 props 将 会 被 共享 。 
通过 createClass 创建 自 定 义 组 件 ， 利 用 原型 继承 ReactCLassComponent 父 类 ， 按 顺序 合并 
mixin， 设 置 初始 化 defaultProps， 返 回 构造 函数 。 


当 使 用 ES6 classes 编写 React 组 件 时 ，class MyComponent extends React.Component 其 实 就 
是 调用 内 部 方法 createclass 创建 组 件 , 相关 代码 如 下 ( 源码 路 径 : /v15.0.0/src/isomorphic/classic/ 
class/ReactClass.js#L802 ): 





















































var ReactClass = { 
// 创建 自 定 义 组 件 
createClass: function(spec) { 
var Constructor = function(props, context, updater) { 
// 自动 绑 定 
if (this. reactAutoBindpairs.length) { 
bindAutoBindMethods(this); 


this.props = props; 

this.context = context; 

this.refs = emptyObject; 

this.updater = updater || ReactNoopUpdateQueue; 
this.state = null; 
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// ReactClass 没有 构造 函数 ， 通 过 getInitialState 和 componentWillMount 来 代替 
var initialState = this.getInitialState ? this.getInitialState() : null; 
this.state = initialState; 


}; 


// 原型 继承 父 类 


Constructor .prototype = new ReactClassComponent(); 
Constructor .prototype.constructor = Constructor; 
Constructor .prototype.__reactAutoBindpairs = []; 


// 合并 mixin 


injectedMixins.forEach( 
mixSpecIntoComponent.bind(null, Constructor) 


); 


mixSpecIntoComponent(Constructor, spec); 


// 所 有 mixin 合并 后 初始 化 defauLtProps( 在 整个 生命 周期 中 ，getDefauLtProps 只 执行 一 次 ) 
if (Constructor .getDefauLtProps) { 
Constructor .defauLtProps = Constructor .getDefauLtProps(); 


} 


// 减少 查找 并 设置 原型 的 时 间 
for (var methodName in ReactClassInterface) { 
if (!Constructor.prototype[methodName]) { 
Constructor .prototype[methodName] = null; 


} 
} 


return Constructor; 
}, 
}; 


2. 阶段 一 : MOUNTING 











mountComponent 负责 管理 生命 周期 中 的 getInitialState 、componentWillMount 、render 和 


componentDidMount。 





由 于 getDefaultProps 是 








通过 构造 函数 进行 管理 的 ， 所 以 也 是 整个 生命 周期 中 最 先 开始 执行 





的 。 而 mountComponent 只 能 望 洲 


Props 只 执行 一 次 。 














EF 兴叹 ,无 法 调用 到 getDefauLtProps。 这 就 解释 了 为 何 getDefault- 


由 于 通过 ReactCompositeComponentBase 返回 的 是 一 个 虚拟 节点 ,所 以 需要 利用 instantiate- 











ReactComponent 去 得 到 实例 ， 再 使 用 mountComponent 拿 到 结果 作为 当前 自 定义 元 素 的 结果 。 












































通过 mountComponent 挂 载 组 件 ， 初始化 序号 、 标 记 等 参数 ,判断 是 否 为 无 状态 组 件 ， 并 进行 
对 应 的 组 件 初始 化 工作 ， 比 如 初始 化 props 、context 等 参数 。 利 用 getInitialstate 获取 初始 化 
state 、 初 始 化 更 新 队列 和 更 新 状态 。 


若 存 在 componentWtLLMount , 则 执行 。 如 果 此 时 在 componentWtLLMount 中 调用 setstate 方 法， 
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是 不 会 触发 re-render 的 ， 而 是 会 进行 state 合并 ， 且 inst.state = this. processPendingState 
(inst.props, inst.context) 是 在 componentWillMount 之 后 执行 的 ， 因 此 componentWtLLMount 中 
的 this.state 并 不 是 最 新 的 ， 在 render 中 才 可 以 获取 更 新 后 的 this.state。 


因此 ，React 是 利用 更 新 队列 this._pendingStateQueue 以 及 更 新 状态 this._pendingReplace 
State 和 this._pendingForceUpdate 来 实现 setstate 的 异步 更 新 机 制 。 


当 泻 染 完成 后 , 若 存 在 componentDidMount, 则 调用 。 这 就 解释 了 componentWillMount 、render 、 
componentDidMount 这 三 者 之 间 的 执行 顺序 。 


其 实 ，mountComponent 本 质 上 是 通过 递归 泻 染 内 容 的 ， 由 于 递归 的 特性 ， 父 组 件 的 
componentWtLLMount 在 其 子 组 件 的 componentWtLLMount 之 前 调用 , 而 父 组 件 的 componentDidMount 
在 其 子 组 件 的 componentDidMount 之 后 调用 。 Se 


mountComponent 的 执行 顺序 如 图 3-11 所 示 。 


mountComponent 


getlnitialstate 
componentWil lMount 












































































创建 Component 实例 
递归 render 


图 3-11 mountComponent 的 执行 顺序 









mountComponent 的 代码 如 下 (源码 路 径 : /v15.0.0/src/renderers/shared/reconciler/React- 


CompositeComponent.js ): 


// 当 组 件 挂 载 时 ， 会 分 配 一 个 递增 编号 ， 表 示 执 行 ReactUpdates 时 更 新 组 件 的 顺序 

var nextNMountID = 1; 

// 初始 化 组 件 ， 洽 染 标 记 ， 注 册 事 件 监 听 器 

mountComponent: function(transaction, nativepParent, nativeContainerInfo, context) { 
// 当前 元 素 对 应 的 上 下 文 


this._context = context; 
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this. mountOrder = nextMountID++; 
this._nativeparent = nativepParent; 
this._nativeContainerInfo = nativeContainerInfo; 


var publicprops = this._processProps(this._currentELement.props ) ; 
var publicContext = this. processContext(context); 


var Component = this._currentElement.type; 


// 初始 化 公共 类 
var inst = this._constructComponent(pubLicProps，pubLicContext) ; 
var renderedELement; 


// 用 于 判断 组 件 是 否 为 stateLess， 无 状态 组 件 没有 状态 更 新 队列 ， 它 只 专注 于 澄 米 
if (!shouLdConstruct(Component) && (inst == null || inst.render == null)) { 
renderedElement = inst; 
warnIfInvalidElement(Component, renderedElement); 
inst = new StatelessComponent(Component); 


} 


// 这 些 初始 化 参数 本 应 该 在 构造 汤 数 中 设置 ， 在 此 设置 是 为 了 便于 进行 简单 的 类 抽象 
inst.props = publicprops; 

inst.context = publicContext; 

inst.refs = emptyObject; 

inst.updater = ReactUpdateQueue; 


this._instance = inst; 


// 将 实例 存储 为 一 个 引用 


ReactInstanceMap.set(inst, this); 


// 初始 化 state 

var initialState = inst.state; 

if (initialState === undefined) { 
inst.state = initialState = null; 


} 


// 初始 化 更 新 队列 

this._ pendingStateQueue = null; 
this._pendingReplaceState = false; 
this._pendingForceUpdate = false; 


var markup; 
// 如 果 挂 载 时 出 现 错误 
if (inst.unstable handleError) { 
markup = this.performInitialMountWithErrorHandling(renderedElement, nativepParent, 
nativeContainerInfo, transaction, context); 
} elsef{ 
// 执行 初始 化 挂 载 
markup = this.performInitialMount(renderedElement, nativepParent, nativeContainerInfo, transaction, 
context); 


} 


// 如 果 存 在 componentDidMount， 则 调用 
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if (inst.componentDidMount) { 
transaction.getReactMountReady().enqueue(inst.componentDidMount, inst); 


} 


return markup; 


} 


performInitialMountWithErrorHandling: function(renderedElement, nativepParent, nativeContainerInfo, 
transaction, context) { 
var markup; 
var checkpoint = transaction.checkpoint(); 


try { 
// 捕 扣 错误， 如 果 没 有 错误 ， 则 初始 化 挂 载 
markup = this.performInitialMount(renderedElement, nativeparent, nativeContainerInfo, transaction, 
context); 
} catch (e) { 
transaction.rollback(checkpoint); 
this._instance.unstable_handleError(e); 
if (this._pendingStateQueue) { 
this._instance.state = this. processPendingState(this._ instance.props, this._ instance.context); 
} 


checkpoint = transaction.checkpoint(); 





// 如 果 捕 捉 到 错误 ， 则 执行 unmountComponent 后 ， 再 初始 化 挂 载 
this._renderedComponent.unmountComponent(true); 
transaction.rollback(checkpoint); 


markup = this.performInitialMount(renderedElement, nativeparent, nativeContainerInfo, transaction, 
context); 
} 


return markup; 


}, 


performInitialMount: function(renderedElement, nativeparent, nativeContainerInfo, transaction, 

context) { 
var inst = this. instance; 
// 如 果 存 在 componentWillMount， 则 调用 
if (inst.componentWillMount) { 

inst.componentWillMount(); 

// componentWillMount 调用 setState 时 ， 不 会 触发 re-render 而 是 自动 提前 合并 

if (this._ pendingStateQueue) { 

inst.state = this. processPendingState(inst.props, inst.context); 


} 
} 
// 如 果 不 是 无 状态 组 件 ， 即 可 开始 澄 染 
if (renderedElement === undefined) { 
renderedELement = this._renderValidatedComponent(); 
} 


this._renderedNodeType = ReactNodeTypes.getType(renderedElement); 
// 得 到 _currentELement 对 应 的 component 类 实例 
this._renderedComponent = this. instantiateReactComponent( 
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renderedELement 

); 

// render 递归 洽 染 

var markup = ReactReconciLer .mountComponent(this._renderedComponent，transaction，nativeParent， 
nativeContainerInfo，this._processChiLdContext(Context) ) ; 


return markup; 


下 
3. 阶段 二 : RECEIVE_PROPS 


updateComponent 负责 管理 生命 周期 中 的 componentWillReceiveProps 、shouldComponent- 
Update 、componentWillUpdate、render 和 componentDidUpdate。 


首先 通过 updateComponent 更 新 组 件 ， 如 果 前 后 元 素 不 一 致 ， 说 明 需 要 进行 组 件 更 新 。 

若 存在 componentWillReceiveProps， 则 执行 。 如 果 此 时 在 componentWtLLReceiveProps 中 调 
用 setstate, 是 不 会 触发 re-render 的 , 而 是 会 进行 state 合并 。 日 在 componentWillReceiveProps、 
shouldComponentUpdate 和 componentWtLLUpdate 中 也 还 是 无 法 获取 到 更 新 后 的 this.state， 即 此 
时 访问 的 this.state 仍然 是 未 更 新 的 数据 ， 需 要 设置 inst.state = nextState 后 才 可 以 ， 因 此 
只 有 在 render 和 componentDidUpdate 中 才能 获取 到 更 新 后 的 this. state。 

调用 shouLdComponentUpdate 判断 是 否 需 要 进行 组 件 更 新 ， 如 果 存 在 componentWtLLUpdate， 
则 执行 。 

updateComponent 本 质 上 也 是 通过 递归 演 染 内 容 的 ， 由 于 递归 的 特性 ， 父 组 件 的 component - 
WLLLUpdate 是 在 其 子 组 件 的 componentWtLLUpdate 之 前 调用 的 ， 而 父 组 件 的 componentDidUpdate 
也 是 在 其 子 组 件 的 componentDidUpdate 之 后 调用 的 。 


当 泻 染 完 成 之 后 ,看 存在 componentDidUpdate， 则 触发 ,这 就 解释 了 componentWillReceive- 
Props、componentNtLLUpdate 、 render 、componentDidUpdate 它们 之 间 的 执行 顺序 。 




























































































注意 ”禁止 在 shouLdComponentUpdate 和 componentWillUpdate 中 调用 setState， 这 会 造成 循环 
调用 ， 直 至 耗 光 浏 览 器 内 存 后 前 渍 。 


updateComponent 的 执行 顺序 如 图 3-12 所 示 。 
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updateComponent 


componentWillReceivProps 
Y 
shouldComponentUpdate 
Y 
componentWillUpdate 
创建 Component 实例 
递归 render 

componentDidUpdate 


图 3-12 updateComponent 的 执行 顺序 


updateComponent 相关 源码 如 下 : 




















// receiveComponent 是 通过 调用 updateComponent 进行 组 件 更 新 的 
receiveComponent: function(nextElement, transaction, nextContext) { 
var prevELement = this. _ currentElement; 
var prevContext = this._context; 


this. pendingElement = null; 


this.updateComponent(transaction, prevElement, nextElement, prevContext, nextContext); 


}, 


updateComponent: function(transaction, prevParentElement, nextParentElement, prevUnmaskedContext, 
nextUnmaskedContext) { 

var inst = this. instance; 

var willReceive = false; 

var nextContext; 

Var nextProps; 


// 上 下 文 是 否 改 变 


if (this._context === nextUnmaskedContext) { 
nextContext = inst.context; 
} else { 


nextContext = this._ processContext(nextUnmaskedContext); 
willReceive = true; 
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if (prevParentELement === nextParentELement) { 
// 如 果 元 素 相同 ， 则 跳 过 元 素 类 型 检测 
nextProps = nextParentELement.props; 

} elsef{ 
// 检测 元 素 类 型 
nextpProps = this._processProps(nextParentELement.props); 
willReceive = true; 

} 

// 如 果 存 在 componentWillReceiveProps， 则 调用 

if (willReceive && inst.componentWillReceiveprops) { 
inst.componentWillReceivepProps(nextProps, nextContext); 


} 


// 将 新 的 state 合并 到 更 新 队列 中 ， 此 时 nextState 为 最 新 的 state 
var nextState = this. processPendingState(nextProps, nextContext); 


// 根据 更 新 队列 和 shouldComponentUpdate 的 状态 来 判断 是 否 需 要 更 新 组 件 
var shouldUpdate = 
this._pendingForceUpdate || 
!inst.shouldComponentUpdate || 
inst.shouldComponentUpdate(nextProps, nextState, nextContext); 


if (shouldUpdate) { 
// 重 置 更 新 队列 
this._pendingForceUpdate = false; 
// 即将 更 新 this.props、this.state 和 this.context 
this._performComponentUpdate(nextParentELement，nextProps，nextState，nextContext，transaction， 

nextUnmaskedContext); 

} elsef{ 
// 如 果 确 定 组 件 不 更 新 ,仍然 要 设置 props 和 state 
this._ currentElement = nextParentELement; 
this._ context = nextUnmaskedContext; 
inst.props = nextProps; 
inst.state = nextState; 
inst.context = nextContext; 

} 

}， 


// 当 确 定 组 件 需要 更 新 时 ， 则 调用 
_performComponentUpdate: function(nextElement, nextProps, nextState, nextContext, transaction, 
unmaskedContext) { 

var inst = this._instance; 

var hasComponentDidUpdate = Boolean(inst.componentDidUpdate); 

Var prevProps; 

var prevState; 

Var prevContext; 


// 如 果 存 在 componentDidUpdate， 则 将 当前 的 props、state 和 context 保存 一 份 
if (hasComponentDidUpdate) { 

prevProps = inst.props; 

prevState = inst.state; 

prevContext = inst.context; 


} 
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// 如 果 存 在 componentWillUpdate， 则 调用 
if (inst.componentWillUpdate) { 
inst.componentWillUpdate(nextProps, nextState, nextContext); 


this._currentElement = nextElement; 
this._context = unmaskedContext; 


// 更 新 this.props、this.state 和 this.context 
inst.props = nextProps; 

inst.state = nextState; 

inst.context = nextContext; 


// 调用 render 泻 染 组 件 


this._updateRenderedComponent(transaction, unmaskedContext); 


// 当 组 件 完成 更 新 后 ， 如 果 存 在 componentDidUpdate， 则 调用 
if (hasComponentDidUpdate) { 
transaction.getReactMountReady() .enqueue( 
inst.componentDidUpdate.bind(inst, prevProps, prevState, prevContext), 
inst 
); 
} 
]， 


// 调用 render 洽 染 组 件 

_updateRenderedComponent: function(transaction, context) { 
var prevComponentInstance = this._renderedComponent; 
var prevRenderedELement = prevComponentInstance._currentElement; 
var nextRenderedELement = this._renderValidatedComponent(); 


// 如 果 需 要 更 新 ， 则 调用 ReactReconciler.receiveComponent 继续 更 新 组 件 
if (shouldUpdateReactComponent(prevRenderedElement, nextRenderedElement)) { 
ReactReconciler.receiveComponent(prevComponentInstance, nextRenderedElement, transaction, 
this._processChildContext(context)); 
} else { 
// 如 果 不 需要 更 新 ， 则 泻 染 组 件 
var oldNativeNode = ReactReconciler .getNativeNode(prevComponentInstance ) ; 
ReactReconciLer .unmountComponent(prevComponentInstance); 


this._renderedNodeType = ReactNodeTypes.getType(nextRenderedELement ) ; 

// 得 到 nextRenderedELement 对 应 的 component 类 实例 

this._renderedComponent = this._instantiateReactComponent( 
nextRenderedELement 


); 
// 使 用 render 递归 澄 染 
var nextMarkup = ReactReconciLer .mountComponent(this._renderedComponent，transaction， 


this._nativeparent, this. nativeContainerInfo, this. _ processChildContext(context)); 


this._replaceNodeWithMarkup(oldNativeNode, nextMarkup); 
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4. 阶段 三 : UNMOUNTING 





unmountComponent 负责 管理 生命 周期 中 的 componentwillUnmount。 


如 果 存 在 componentWtLLUnmount ， 则 执行 并 重 置 所 有 相关 参数 、 更 新 队列 以 及 更 新 状态 ， 如 
果 此 时 在 componentWtLLUnmount 中 调用 setState， 是 不 会 触发 re-render 的 ， 这 是 因为 所 有 更 新 
队列 和 更 新 状态 都 被 重 置 为 nutL， 并 清除 了 公共 类 ， 完 成 了 组 件 件 载 操作 。unmountComponent 的 
代码 如 下 : 


unmountComponent: function(safely) { 


} 




















if (!this._ renderedComponent) { 
return; 


} 


var inst = this._ instance; 


// 如 果 存 在 componentWillUnmount， 则 调用 
if (inst.componentWillUnmount) { 
if (safely) { 
var name = this.getName() + '.componentWillUnmount()'; 
ReactErrorUtils.invokeGuardedCallback(name, inst.componentWillUnmount.bind(inst)); 
} else { 
inst.componentWillUnmount(); 


} 


} 


// 如 果 组 件 已 经 澄 染 ， 则 对 组 件 进行 unmountComponent 操作 
if (this._renderedComponent) { 
ReactReconciler .unmountComponent(this._renderedComponent, safely); 
this._renderedNodeType = null; 
this._renderedComponent = null; 
this. instance = null; 


} 


// 重 置 相关 参数 、 更 新 队列 以 及 更 新 状态 
this._pendingStateQueue = null; 
this._pendingReplaceState = false; 
this._pendingForceUpdate = false; 
this._pendingCallbacks = null; 

this. pendingElement = null; 
this._context = null; 
this._rootNodeID = null; 
this._topLevelWrapper = null; 


// 清除 公共 类 


Reactinetarcenap Ferovectnsty, 





至 此 , 我 们 跟随 着 React 源码 的 脚步 完整 地 了 解 其 生命 周期 的 执行 过 程 , 你 是 否 已 经 对 React 
生命 周期 有 了 更 深刻 的 理解 了 呢 ? 











命 周 期 和 state 状态 让 React 组 件 无 比 灵活 与 强大 ， 同 时 也 使 得 组 件 变 得 复杂 而 难以 维护 。 
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在 实际 的 项 目 开 发 中 ， 我 们 经 常 需要 编写 一 些 自身 没有 状态 ， 只 是 从 父 组 件 接受 props， 并 根据 
这 些 属性 进行 泻 染 的 简单 组 件 ， 这 不 仅 让 组 件 的 开发 变 得 简单 、 高 效 ,， 也 便于 对 状态 进行 统一 管 
理 。 因 此 ， 在 React 开发 中 ， 一 个 很 重要 的 原则 就 是 让 组 件 尽 可 能 是 无 状态 的 。 

当然 ，React 官方 也 是 鼓励 这 一 原则 的 。 在 React 0.14 之 后 ， 便 推出 了 无 状态 组 件 ， 大 大 增 
强 了 React 组 件 编写 的 便捷 性 ， 也 提升 了 整体 的 泻 染 性 能 。 



































3.3.3 ”无 状态 组 件 
我 们 在 1.3 方 中 提 到 过 无 状态 组 件 。 无 状态 组 件 只 是 一 个 render 方法 , 并 没有 组 件 类 的 实例 
化 过 程 ， 也 没有 实例 返回 。 比 如 : 


const HelloWorld = (props) => <div>{props.name}</div>; 
ReactDOM. render(<HelloWorld name="Hello World!" />, App); 


render 子 数 和 shouLdConstruct 函数 的 代码 如 下 (源码 路 径 : /v15.0.0/src/renderers/shared/re- 


conciler/ReactCompositeComponent.js ): 








// 无 状态 组 件 只 有 一 个 render 函数 

StateLessComponent .prototype.render = function() { 
var Component = ReactInstanceMap.get(this)._currentElement.type; 
// 没有 state 状态 
var element = Component(this.props, this.context, this.updater); 
warnIfInvalidElement(Component, element); 
return element; 


}; 


function shouldConstruct(Component) { 
return Component.prototype && Component.prototype.isReactComponent; 


} 

无 状态 组 件 没有 状态 ,没有 生命 周期 ， 只 是 简单 地 接受 props 演 染 生成 DOM 结构 ， 是 一 个 
纯粹 为 演 染 而 生 的 组 件 。 由 于 无 状态 组 件 有 简单 、 便 捷 、 高 效 等 诸多 优点 ， 所 以 如 果 可 能 的 话 ， 
请 尽量 使 用 无 状态 组 件 。 

最 后 用 一 张 图 再 次 归纳 一 下 生命 周期 ， 如 图 3-13 所 示 。 
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图 3-13 生命 周期 全 局 图 





3.4 解密 setState 机 制 


state 是 React 中 重要 的 概念 。 第 1 章 中 提 到 过 ，React 是 通过 管理 状态 来 实现 对 组 件 的 管理 。 
那么 ，React 是 如 何 控制 组 件 的 状态 的 ， 又 是 如 何 利 用 状态 来 管理 组 件 的 呢 ? 


众所周知 ，React 通过 this.state 来 访问 state， 通 过 this.setState() 方法 来 更 新 state。 当 
this.setState() 被 调用 的 时 候 ，React 会 重新 调用 render 方法 来 重新 演 染 UI。 

想必 setState 已 经 是 我 们 再 熟悉 不 过 的 API， 然 而 你 真 的 了 解 它 吗 ? 本 节 将 为 我 们 解密 
setState 的 更 新 机 制 。 





















































3.4.1 setState 异步 更 新 
React 初学 者 常会 写 出 this.state.value = 1 这样 的 代码 ， 这 是 完全 错误 的 写法 。 


注意 ”绝对 不 要 直接 修改 this.state， 这 不 仅 是 一 种 低 效 的 做 法 ,而 且 很 有 可 能 会 被 之 后 的 操 
作 替 换 。 


setState 通过 一 个 队列 机 制 实现 state 更 新 。 当 执行 setstate 时 ， 会 将 需要 更 新 的 state 合并 
后 放 入 状态 队列 ， 而 不 会 立刻 更 新 thtis.state， 队 列 机 制 可 以 高 效 地 批量 更 新 state。 如 果 不 通过 
setState 而 直接 修改 this.state 的 值 ， 那 么 该 state 将 不 会 被 放 和 人 状态 队列 中 ， 当 下 次 调用 
setState 并 对 状态 队列 进行 合并 时 ， 将 会 忽略 之 前 直接 被 修改 的 state， 而 造成 无 法 预知 的 错误 。 
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因此 , 应 该 使 用 setstate 方法 来 更 新 state， 同 时 React 也 正 是 利用 状态 队列 机 制 实现 了 setState 
的 异步 更 新 ， 避 免 频 繁 地 重复 更 新 state。 相 关 代 码 如 下 : 


// 将 新 的 state 合并 到 状态 更 新 队列 中 


var nextState = this._ processPendingState(nextProps, nextContext); 








// 根据 更 新 队列 和 shouldComponentUpdate 的 状态 来 判断 是 否 需 要 更 新 组 件 
var shouldUpdate = 
this._pendingForceUpdate || 
!inst.shouldComponentUpdate || 
inst.shouldComponentUpdate(nextProps, nextState, nextContext); 


3.4.2 setstate 循环 调用 风险 


当 调 用 setstate 时 , 实际 上 会 执行 enqueueSetState 方法, 并 对 partialState 以 及 _pending- 
StateQueue 更 新 队列 进行 合并 操作 ， 最 终 通过 enqueueUpdate 执行 state 更 新 。 

而 performUpdateIfNecessary 方 法 会 获取 _pendingElement、_pendingStateQueue 、_pending- 
ForceUpdate， 并 调用 receiveComponent 和 updateComponent 方法 进行 组 件 更 新 。 























如 果 在 shouLdComponentUpdate 或 componentNtLLUpdate 方法 中 调用 setstate ， 此 时 
this._pendingStateQueue != nuLL， 则 performUpdateIfNecessary 方法 就 会 调用 updateComponent 
方法 进行 组 件 更 新 , 但 updateComponent 方法 又 会 调用 shouldComponentUpdate 和 componentWill- 
Update 方法 ， 因 此 造成 循环 调用 ， 使 得 浏览 器 内 存 占 满 后 朋 演 ， 如 图 3-14 所 示 。 
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图 3-14 循环 调用 





接着 我 们 来 看 setstate 的 源码 : 


// 更 新 state 
ReactComponent .prototype.setState = function(partialState, callback) { 
this .updater .enqueueSetState(this, partialState); 
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if (callback) { 
this .updater .enqueueCallback(this, callback, 'setState'); 
} 
}; 


enqueueSetState: function(publicInstance, partialState) { 
var internalInstance = getInternaLInstanceReadyForUpdate( 
publicInstance, 
"SetState' 
); 


if (!internalInstance) { 
return; 


} 


// 更 新 队列 合并 操作 


var queue = internaLInstance._pendingStateQueue || (internalInstance._pendingStateQueue = []); 


queue.push(partialState); 
enqueueUpdate(internalInstance); 


}, 


// 如 果 存 在 _pendingElement、_pendingStateQueue 和 _pendingForceUpdate， 则 更 新 组 件 
performUpdateIfNecessary: function(transaction) { 
if (this._ pendingElement != nuLL) { 
ReactReconciler.receiveComponent(this, this. pendingElement, transaction, this. _ context); 
} 
if (this. _ pendingStateQueue !== null || this. pendingForceUpdate) { 
this.updateComponent(transaction, this._currentElement, this._currentElement, this._context, 
this._context); 


3.4.3 ”setState 调用 栈 



































既然 setstate 最 终 是 通过 enqueueUpdate 执行 state 更 新 ， 那 么 enqueueUpdate 到 底 是 如 何 更 
新 state 的 呢 ? 


首先 ， 看 看 下 面 这 个 问题 ， 你 是 否 能 够 正确 回答 呢 ? 


import React, { Component } from 'react'; 




















class Example extends Component { 
constructor() { 
super(); 
this.state = { 
val: 0 
}; 
} 


componentDidMount() { 
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this.setState({val: this.state.val + 1}); 
console.log(this.state.val); // 第 1 次 输出 


this.setState({val: this.state.val + 1}); 
console.log(this.state.val); // 第 2 次 输出 


setTimeout(() => { 
this.setState({val: this.state.val + 1}); 
console.log(this.state.val); // 第 3 次 输出 


this.setState({val: this.state.val + 1}); 
console.log(this.state.val); // 第 4 次 输出 
}, 0); 
} 


render() { 
return null; 
} 
} 


上 述 代 码 中 ，4 次 console.1log 打印 出 来 的 vat 分 别 是 : 0、0、2、3。 
假如 结果 与 你 心中 的 答案 不 完全 相同 ， 那 么 你 应 该 会 感 兴 趣 enqueueUpdate 到 底 做 了 什么 ? 
图 3-15 是 一 个 简化 的 setstate 调用 栈 ， 注 意 其 中 核心 的 状态 判断 。 






































this .setState(newState) 
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是 否 处 于 批量 更 新 模式 


遍历 dirtyComponents 
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图 3-15 ”setstate 简化 调 
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enqueueUpdate 的 代码 如 下 (源码 路 径 : /v15.0.0/src/ renderers/shared/reconciler/ReactUpdates. 
js ): 


function enqueueUpdate(component) { 
ensureInjected(); 


// 如 果 不 处 于 批量 更 新 模式 

if (!batchingStrategy.isBatchingUpdates) { 
batchingStrategy.batchedUpdates(enqueueUpdate, component); 
return; 

} 

// 如 果 处 于 批量 更 新 模式 ， 则 将 该 组 件 保存 在 dirtyComponents 中 

dirtyComponents.push(component); 


} 


如 果 isBatchingUpdates 为 true， 则 对 所 有 队列 中 的 更 新 执行 batchedUpdates 方法 ， 否 则 只 
把 当前 组 件 ( 即 调用 了 setstate 的 组 件 ) 放 入 dirtyComponents 数组 中 。 例子 中 4 次 setState 调 
用 的 表现 之 所 以 不 同 ， 这 里 逻辑 判断 起 了 关键 作用 。 

那么 batchingstrategy 究竟 做 什么 呢 ? 其实 它 只 是 一 个 简单 的 对 象 ， 定 义 了 一 个 
isBatchingUpdates 的 布尔 值 ， 以 及 batchedUpdates 方法 (源码 路 径 : /v15.0.0/src/renderers/shared/ 
reconciler/ReactDefaultBatchingStrategy.js ): 


























var ReactDefaultBatchingStrategy = { 
isBatchingUpdates: false, 


batchedUpdates: function(callback, a, b, c, d, e){ 
var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates; 
ReactDefaultBatchingStrategy.isBatchingUpdates = true; 


if (alreadyBatchingUpdates) { 
callback(a, b, c, d, e); 
} else { 
transaction.perform(callback, null, a, b, c, d, e); 
} 
0 
} 


值得 注意 的 是 ， batchedUpdates 方法 中 有 一 个 transaction.perform 调用 ， 这 是 本 章 后 续 要 
介绍 的 核心 概念 一 一 事务 ( transaction )。 


























3.4.4 初 识 事务 
事务 源码 中 有 一 幅 图 ,形象 地 解释 了 它 的 作用 ， 如 图 3-16 所 示 (本 节 的 源码 路 径 : /v15.0.0/ 


src/shared/utils/Transaction.js )。 
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图 3-16 ReactCompositeComponent 流程 图 











事务 就 是 将 需要 执行 的 方法 使 用 wrapper 封装 起 来 ， 再 通过 事务 提供 的 perforn 方法 执行 。 
而 在 perforn 之 前 ， 先 执行 所 有 wrapper 中 的 initialize 方法 ， 执 行 完 perform 之 后 ( 即 执行 
method 方法 后 ) 再 执行 所 有 的 close 方法 。 一 组 initialize 及 close 方法 称 为 一 个 wrapper。 从 
图 3-16 中 可 以 看 出 ， 事 务 支 持 多 个 wrapper 合 加 。 


到 实现 上 ， 事 务 提供 了 一 个 mixin 方法 供 其 他 模块 实现 自己 需要 的 事务 。 而 要 使 用 事务 的 模 
块 ， 除了 需要 把 mixin 混入 自己 的 事务 实现 中 外 ， 还 要 额外 实现 一 个 抽象 的 getTransaction- 
Wrappers 接口 。 这 个 接口 用 来 获取 所 有 需要 封装 的 前 置 方法 (initialize ) 和 收尾 方法 (close )， 
因此 它 需 要 返回 一 个 数组 的 对 象 ， 每 个 对 象 分 别 有 key 为 initialize 和 close 的 方法 。 

下 面 是 一 个 简单 使 用 事务 的 例子 : 


var Transaction = require('./Transaction'); 
























































// 我 们 自己 定义 的 事务 

var MyTransaction = function() { 
[fs 

}; 
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Object 
getT 
re 


}] 
}; 
}); 


var tr 
var te 
cons 


} 


transa 


.assign(MyTransaction.prototype, Transaction.Mixin, { 
ransactionWrappers: function() { 
turn [{ 
initialize: function() { 
console.log('before method perform'); 
}， 
close: function() { 
console.log('after method perform'); 


} 


A 


ansaction = new MyTransaction(); 
stMethod = function() { 
ole.log('test'); 


ction.perform(testMethod); 


// 打印 的 结果 如 下 : 
// before method perform 


// tes 
// aft 


翻 看 源码 。 


3.4.5 角 


t 
er method perform 


在 React 中 还 做 了 异常 处 理 等 工作 ， 这 里 就 不 详细 展开 了 。 如 果 你 有 兴趣 ， 可 以 继续 





孚 密 setState 


说 了 这 么 多 ， 事 务 到 底 是 怎么 导致 前 面 所 述 的 setState 的 各 种 不 同 表 现 的 呢 ? 

这 里 我 们 先 要 了 解 事务 跟 setstate 的 不 同 表现 有 什么 关系 。 首 先 , 我 们 把 4 次 setstate 简单 
归 类 ， 前 两 次 属于 一 类 ， 因 为 它们 在 同一 次 调用 栈 中 执行 ，setTimeout 中 的 两 次 setState 属于 
另 一 类 ， 原 因 同上 。 下 面 我 们 分 别 看 看 这 两 类 setstate 的 调用 栈 ， 如 图 3-17 和 图 3-18 所 示 。 

很 明显 ， 在 componentDidMount 中 直接 调用 的 两 次 setstate ， 其 调用 栈 更 加 复杂 ; 而 
setTimeout 中 调用 的 两 次 setstate， 其 调用 栈 则 简单 很 多 。 下 面 重点 看 看 第 一 类 setstate 的 调 
用 栈 ， 有 没有 发 现 什 么 ? 没 错 ， 就 是 batchedUpdates 方法 ， 原 来 早 在 setstate 调用 前 ,已 经 处 
于 batchedUpdates 执行 的 事务 中 了 。 

那 这 次 batchedUpdate 方 法 ,又 是 谁 调用 的 呢 ?” 让 我 们 往 前 再 追溯 一 层 , 原 来 是 ReactMount.js 
中 的 _renderNewRootComponent 方法 。 也 就 是 说 ， 整 个 将 React 组 件 演 染 到 DOM 中 的 过 程 就 处 于 





一 个 大 的 习 

























































































有 务 中 。 


接 下 来 的 解释 就 顺理成章 了 ,因为 在 componentDidMount 中 调用 setstate 时 ,batchingStrategy 
的 isBatchingUpdates 已 经 被 设 为 true， 所 以 两 次 setState 的 结果 并 没有 立即 生效 ， 而 是 被 放 进 
了 dirtyComponents 中 。 这 也 解释 了 两 次 打印 this.state.val 都 是 0 的 原因 ， 因 为 新 的 state 还 没 
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有 被 应 用 到 组 件 中 。 
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图 3-17 
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(anonymous function) 


componentDidMount 中 setstate 的 调 


ReactComponent.js:64 
index.js:11 
CallbackQueue.js:65 
ReactReconcileT...nsaction.js:81 
Transaction.js:202 
Transaction.js:149 
ReactMount.js:282 
Transaction.js:136 
ReactDefaultBat...Strategy.js:62 
ReactUpdates.js:94 
ReactMount.js:476 
ReactPerf.js:66 
ReactMount.js:545 
ReactMount.js:565 
ReactPerf.js:66 
deprecated.js:38 

index.js:29 


栈 














工 





ReactComponent.js:64 
index.js:17 


setTimeout (async) 


Example_componentDidMount 
图 3-18 


再 反观 setTimeout 中 的 两 次 setState ， 


index.js:16 

















setTimeout 中 setstate 的 调用 栈 





因为 没有 前 置 的 batchedupdate 调 用 ， 所 以 





batchingStrategy 的 isBatchingUpdates 标志 位 是 faLse， 也 就 导致 了 新 的 state 马上 生效 ,没有 
走 到 dirtyComponents 分 支 。 也 就 是 说 ，setTimeout 中 第 一 次 执行 setState 时 ，this.state.val 
为 1， 而 setState 完成 后 打印 时 this.state.vat 变 成 了 2。 第 二 次 的 setState 同 理 。 


前 面 介 绍 事务 时 ， 也 提 到 了 其 在 React 源 码 中 的 多 人 处 应 用 , 像 initialize、perform、close、 
cLoseALL 、notifyALL 等 方法 出 现在 调用 栈 中 ， 都 说 明 当 前 处 于 一 个 事务 中 。 

既然 事务 这 么 有 用 ， 我 们 写 应 用 代码 时 能 使 用 它 吗 ? 很 可 惜 ， 答 案 是 不 能 。 尽 管 React 不 建 
议 我 们 直接 使 用 事务 ， 但 在 React 15.0 之 前 的 版 本 中 还 是 为 开发 者 提供 了 batchedUpdates 方法 ， 
它 可 以 解决 针对 一 开始 例子 中 setTimeout 里 的 两 次 setState 导致 两 次 render 的 情况 : 























import ReactDOM，{ unstable_batchedUpdates } from 'react-dom'; 


unstable_batchedUpdates(() => { 
this.setState(val: this.state.val + 1); 
this.setState(val: this.state.val + 1); 
]); 
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在 React15.0 以 及 之 后 版 本 中 ， 已 经 彻底 将 batchedupdates 这 个 API 移 除了 ， 因 此 不 再 建议 
开发 者 使 用 它 。 





3.5 diff 算法 


di 在 作为 Virtual DOM 的 加 速 器 ， 其 算法 上 的 改进 优化 是 React 整个 界面 泻 染 的 基础 和 性 能 
保障 , 同时 也 是 React 源码 中 最 神秘 、 最 不 可 思议 的 部 分 。 本 节 依 然 从 源码 人 手 , 深入 剖析 di 企 的 
不 可 思议 之 处 。 

React 中 最 值得 称道 的 部 分 莫 过 于 Virtual DOM 模型 与 diff 的 完美 结合 ， 特 别 是 其 高 效 的 
di 企 算 法 ， 可 以 让 用 户 无 需 顾 鼠 性 能 问题 而 “任性 自由 ”地 刷新 页 面 ， 让 开发 者 也 可 以 无 需 关心 
Virtual DOM 背后 的 运作 原理 。 因 为 diff 会 帮助 我 们 计算 出 Virtual DOM 中 真正 变化 的 部 分 ， 并 
只 针对 该 部 分 进行 原生 DOM 操作 ， 而 非 重新 泻 染 整个 页 面 ， 从 而 保证 了 每 次 操作 更 新 后 页 面 
的 高 效 泻 染 。 因 此 ，Virtual DOM 模型 与 diff 是 保证 React 性 能 口碑 的 幕后 推手 。 


di 全 算法 也 并 非 其 首创 。 正 是 因为 该 算法 的 普 适 度 高 ， 就 更 应 该 认可 React 针对 diff 算法 优 
化 所 做 的 努力 与 贡献 ， 这 更 能 体现 React 创作 者 们 的 魅力 与 智慧 ! 











































































































3.5.1 传统 diff 算法 


计算 一 棵 树 形 结构 转换 成 另 一 棵 树 形 结构 的 最 少 操作 , 是 一 个 复杂 且 值 得 研究 的 问题 。 传 统 
di 在 算法 "通过 循环 递归 对 节点 进行 依次 对 比 ， 效 率 低下 ， 算 法 复杂 度 达 到 O(m)， 其 中 是 树 中 
节点 的 总 数 。O02 到 底 有 多 可 怕 呢 ? 这 意味 着 如 果 要 展示 1000 个 节点 ， 就 要 依次 执行 上 十 亿 次 
的 比较 。 这 种 指数 型 的 性 能 消耗 对 于 前 端 泻 染 场 景 来 说 代价 太 高 了 。 如 今 的 CPU 每 秒 钟 能 执行 
大 约 30 亿 条 指令 ， 即 便 是 最 高 效 的 实现 ， 也 不 可 能 在 一 秒 内 计算 出 差异 情况 。 

因此 ， 如 果 React 只 是 单纯 地 引入 di 在 算法 而 没有 任何 的 优化 改进 ， 那 么 其 效率 远 远 无 法 满 
足 前 端 泻 染 所 要 求 的 性 能 。 如 果 想 要 将 di 在 思想 引入 Virtual DOM , 就 要 设计 一 种 稳定 、 高 效 的 diff 
算法 ， 这 个 React 做 到 了 ! 

那么 ，diff 到 底 是 如 何 实现 的 呢 ? 

























































































3.5.2 详解 diff 


React 将 Virtual DOM 树 转换 成 actual DOM 树 的 最 少 操 作 的 过 程 称 为 调和 (reconciliation )。 
di 人 f 算 法 便 是 调和 的 具体 实现 。 那 么 这 个 过 程 是 怎么 实现 的 呢 ? 














QD A Survey on Tree Edit Distance and Related Problems， 详 见 http://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_ 
bille.pdf。 
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React 通过 制定 大 胆 的 策略 ， 将 O(n ) 复杂 度 的 问题 转换 成 O(n) 复杂 度 的 问题 。 
1. diff 策略 
下 面 介绍 React di 企 算 法 的 3 个 策略 。 
口 策略 一 : Web UI 中 DOM 节点 跨 层级 的 移动 操作 特别 少 ， 可 以 忽略 不 计 。 
口 策略 二 : 拥有 相同 类 的 两 个 组 件 将 会 生成 相似 的 树 形 结构 ， 拥 有 不 同类 的 两 个 组 件 将 会 
生成 不 同 的 树 形 结构 。 
口 策略 三 : 对 于 同一 层级 的 一 组 子 节 点 ， 它 们 可 以 通过 唯一 id 进行 区 分 。 

基于 以 上 策略 ，React 分 别 对 tree diff、component diff 以 及 element diff 进行 算法 优化 。 习 
也 证 明 这 3 个 前 提 策 略 是 合理 且 准 确 的 ， 它 保证 了 整体 界面 构建 的 性 能 。 

2. tree diff 

基于 策略 一 ，React 对 树 的 算法 进行 了 简洁 明了 的 优化 ， 即 对 树 进行 分 层 比较 ， 两 棵 树 只 会 
同一 层次 的 节点 进行 比较 。 
既然 DOM 节点 跨 层级 的 移动 操作 少 到 可 以 忽略 不 计 , 针 对 这 一 现象 ,React 通过 updateDepth 
对 Virtual DOM 树 进 行 层级 控制 ， 只 会 对 相同 层级 的 DOM 节点 进行 比较 ， 即 同一 个 父 节 点 下 的 
所 有 子 节 点 。 当 发 现 节 点 已 经 不 存在 时 ， 则 该 节点 及 其 子 节 点 会 被 完全 删除 掉 , 不 会 用 于 进一步 
的 比较 。 这 样 只 需要 对 树 进行 一 次 遍历 ， 便 能 完成 整个 DOM 树 的 比较 。 

updateChildren 方法 对 应 的 源码 如 下 : 


























由 
党 











> 


























updateChildren: function(nextNestedChildrenElements, transaction, context) { 
updateDepth++; 
var errorThrown = true; 
try { 
this._ updateChildren(nextNestedChildrenElements, transaction, context); 
errorThrown = false; 
} finally { 
updateDepth--; 
if (!updateDepth) { 
if (errorThrown) { 
clearQueue(); 
} elsef{ 
processQueue(); 
} 
} 
} 
} 


你 可 能 存在 这 样 的 疑问 : 如 果 出 现 了 DOM 节点 跨 层级 的 移动 操作 , diff 会 有 怎样 的 表现 呢 ? 
我 们 不 妨 试验 一 番 。 

如 图 3-19 所 示 ，A 节点 (包括 其 子 节 点 ) 整个 被 移动 到 D 节点 下 ， 由 于 React 只 会 简单 地 
考虑 同 层 级 节点 的 位 置 变换 ， 而 对 于 不 同 层级 的 节点 ， 只 有 创建 和 删除 操作 。 当 根 节 点 发 现 子 节 
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点 中 人 A 消失 了 ， 就 会 直接 销毁 A; 当 D 发 现 多 了 一 个 子 节 点 A， 则 会 创建 新 的 A (包括 子 节点 ) 
作为 其 子 节 点 。 此 时 ，diff 的 执行 情况 : create A 一 create B 一 create C 一 delete A。 











图 3-19 DOM 层级 变换 
由 此 可 以 发 现 ， 当 出 现 节 点 跨 层级 移动 时 ， 并 不 会 出 现 想象 中 的 移动 操作 ,而 是 以 A 为 根 节 


点 的 整个 树 被 重新 创建 。 这 是 一 种 影响 React 性 能 的 操作 ， 因 此 官方 建议 不 要 进行 DOM 节点 跨 
层级 的 操作 。 








注意 ”在 开发 组 件 时 ， 保 持 稳定 的 DOM 结构 会 有 助 于 性 能 的 提升 。 例 如 ， 可 以 通过 CSS 隐藏 
或 显示 节点 ， 而 不 是 真正 地 移 除 或 添加 DOM 节点 。 


3. component diff 

React 是 基于 组 件 构 建 应 用 的 ， 对 于 组 件 间 的 比较 所 采取 的 策略 也 是 非常 简洁 、 高 效 的 。 

口 如 果 是 同一 类 型 的 组 件 ， 按 照 原 策略 继续 比较 Virtual DOM 树 即 可 。 

口 如 果 不 是 ， 则 将 该 组 件 判 断 为 dirty component， 从 而 替换 整个 组 件 下 的 所 有 子 节点 。 

口 对 于 同一 类 型 的 组 件 ， 有 可 能 其 Virtual DOM 没有 任何 变化 ， 如 果 能 够 确切 知道 这 点 , 那 
么 就 可 以 节省 大 量 的 diff 运算 时 间 。 因 此 ，React 允许 用 户 通 过 shouLdComponentUpdate() 
来 判断 该 组 件 是 否 需 要 进行 diff 算 法 分 析 。 


如 图 3-20 所 示 ， 当 组 件 D 变 为 组 件 G 时 ， 即 使 这 两 个 组 件 结 构 相 似 ， 一 旦 React 判断 DD 和 
G 是 不 同类 型 的 组 件 ， 就 不 会 比较 二 者 的 结构 ,而 是 直接 删除 组 件 D, 重新 创建 组 件 G 及 其 子 节 
点 。 昌 然 当 两 个 组 件 是 不 同类 型 但 结构 相似 时 ，diff 会 影响 性 能 ， 但 正如 React 官方 博客 所 言 : 
不 同类 型 的 组 件 很 少 存在 相似 DOM 树 的 情况 ， 因 此 这 种 极端 因素 很 难 在 实际 开发 过 程 中 造成 重 
大 的 影响 。 
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图 3-20 component diff 


4. element diff 


当 节 点 处 于 同一 层级 时 ，diff 提供 了 3 种 节点 操作 ， 分 别 为 INSERT_MARKUP (插入 )、MOVE_ 
EXISTING ( 移动 ) 和 REMOVE_NODE (删除 )。 


口 INSERT_MARKUP: 新 的 组 件 类 型 不 在 旧 和 集合 里 , 即 全 新 的 节点 , 需要 对 新 节点 执行 插入 操作 。 

口 MOVE_EXISTING: 旧 集 合 中 有 新 组 件 类 型 , 日 element 是 可 更 新 的 类 型 , generateComponent- 
Children 已 调用 receiveComponent， 这 种 情况 下 prevChiLd=nextChiLd， 就 需要 做 移动 操 
作 ， 可 以 复 用 以 前 的 DOM 节点 。 

口 REMOVE_NODE: 旧 组 件 类 型 ,在 新 集合 里 也 有 , 但 对 应 的 element 不 同 则 不 能 直接 复 用 和 更 

新 ， 需 要 执行 删除 操作 ， 或 者 旧 组 件 不 在 新 集合 里 的 ， 也 需要 执行 删除 操作 。 


相关 代码 如 下 : 


function makeInsertMarkup(markup, afterNode, toIndex) { 
return { 
type: ReactMultiChildUpdateTypes.INSERT_MARKUP, 
content: markup, 
fromIndex: null, 
fromNode: null, 
toIndex: toIndex, 
afterNode: afterNode, 
}; 
} 





ly 












































function makeMove(child, afterNode, toIndex) { 
return { 
type: ReactMultiChildUpdateTypes.MOVE_EXISTING, 
content: null, 
fromIndex: child. mountIndex, 
fromNode: ReactReconciler .getNativeNode(child), 
toIndex: toIndex, 
afterNode: afterNode, 
}; 
} 


function makeRemove(child, node) { 
return { 
type: ReactMultiChildUpdateTypes .REMOVE_NODE ， 
content: null, 
fromIndex: child. mountIndex, 
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fromNode: node, 
toIndex: null, 
afterNode: null, 
}; 

} 

如 图 3-21 所 示 ， 旧 和 集合 中 包含 节点 A、B、C 和 DDD， 更 新 后 的 新 集合 中 包含 节点 B、A、D 和 
C， 此 时 新 旧 和 集合 进行 diff 差 异化 对 比 ， 发 现 B != A， 则 创建 并 插入 B 至 新 集合 ， 删 除 旧 集合 A; 
以 此 类 推 , 创建 并 插入 A、D 和 C， 删除 B、C 和 了 D。 


COO 
5 


图 3-21 节点 di 在 


React 发 现 这 类 操作 烦琐 宛 余 ， 因 为 这 些 都 是 相同 的 节点 ， 但 由 于 位 置 发 生变 化 ， 导 致 需要 
进行 繁杂 低 效 的 删除 、 创 建 操作 ， 其 实 只 要 对 这 些 节 点 进行 位 置 移动 即 可 。 

针对 这 一 现象 , React 提出 优化 策略 : 允许 开发 者 对 同一 层级 的 同 组 子 节点 , 添加 唯一 key 进 
行 区 分 ， 虽然 只 是 小 小 的 改动 ， 性 能 上 却 发 生 了 翻天 履 地 的 变化 ! 
新 旧 集 合 所 包含 的 节点 如 图 3-22 所 示 ， 进 行 diff 差异 化 对 比 后 ， 通 过 key 发 现 新 旧 集 合 中 
的 节点 都 是 相同 的 节点 ,因此 无 需 进行 节点 删除 和 创建 , 只 需要 将 旧 集 合 中 节点 的 位 置 进行 移动 ， 
更 新 为 新 集合 中 节点 的 位 置 ， 此 时 React 给 出 的 di 在 结 果 为 : B、DD 不 做 任何 操作 ，A 、C 进行 移 
动 操作 即 可 。 
那么 ， 如 此 高 效 的 diff 到 底 是 如 何 运 作 的 呢 ?” 让 我 们 通过 源码 详细 分 析 一 下 。 
首先 ， 对 新 集合 中 的 节点 进行 循环 遍历 for (name in nextChildren)， 通 过 唯一 的 key 判断 
新 旧 集 合 中 是 否 存 在 相同 的 节点 if (prevChild === nextChittd) ， 如 果 存 在 相同 节点 ， 则 进行 移 
动 操作 ,但 在 移动 前 需要 将 当前 节点 在 旧 和 集合 中 的 位 置 与 LastIndex 进行 比较 if 
(child._mountIndex < lastIndex)， 否 则 不 执行 该 操作 。 这 是 一 种 顺序 优化 手段 ，lastIndex 一 
直 在 更 新 ， 表 示 访 问 过 的 节点 在 旧 集 合 中 最 右 的 位 置 ( 即 最 大 的 位 置 )。 如 果 新 集合 中 当前 访问 
的 节点 比 lastIndex 大， 说 明 当 前 访问 节点 在 旧 集 合 中 就 比 上 一 个 节点 位 置 靠 后 ， 则 该 节点 不 会 
影响 其 他 节点 的 位 置 ， 因 此 不 用 添加 到 差异 队列 中 ， 即 不 执行 移动 操作 。 只 有 当 访 问 的 节点 比 
LastIndex 小 时 ， 才 需要 进行 移动 操作 。 
图 3-22 为 例 ， 下 面 更 为 清晰 直观 地 描述 diff 的 差异 化 对 比 过 程 。 
口 从 新 集合 中 取得 B， 然 后 判断 旧 集 合 中 是 否 存 在 相同 节点 B， 此 时 发 现存 在 节点 了 B， 接 着 
通过 对 比 节 点 位 置 判 断 是 否 进 行 移动 操作 。B 在 旧 集合 中 的 位 置 B._mountIndex = 1， 此 
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时 LastIndex = 0， 不 满足 child._mountIndex < LastIndex 的 条 件 ， 因 此 不 对 B 进行 移动 
操作 。 更 新 LastIndex = Math.max(prevChild._mountIndex, LastIndex)， 其 中 prevChitLd 
mountIndex 表示 B 在 旧 集 合 中 的 位 置 ， 则 LastIndex = 1， 并 将 B 的 位 置 更 新 为 新 集合 中 的 
位 置 prevChiLd._ mountIndex = nextIndex， 此 时 新 集合 中 B._mountIndex = 6，nextIndex++ 











进入 下 一 个 节点 的 判断 。 





key=b key=a key=d key=c 
图 3-22 ”对 节点 进行 di 在 差 异化 对 比 






































口 从 新 集合 中 取得 A, 然后 判断 旧 集 合 中 是 否 存 在 相同 节点 A， 此 时 发 现存 在 节点 A， 接着 





























通过 对 比 节点 位 置 判断 是 否 进行 移动 操作 。A 在 旧 集 合 中 的 位 置 A._mountIndex = 9， 此 


时 LastIndex = 1， 满 足 child._mountIndex < LastIndex 的 条 件 ， 因 此 对 A 进行 移动 操作 
enqueueMove(this, child._mountIndex, toIndex)， 其 中 toIndex 其 实 就 是 nextIndex， 表 
示 A 需 要 移动 到 的 位 置 。 更 新 LastIndex = Math.max(prevChild._mountIndex, lastIndex)， 
则 1LastIndex = 1， 并 将 A 的 位 置 更 新 为 新 集合 中 的 位 置 prevChild._mountIndex 
nextIndex， 此 时 新 集合 中 A._mountIndex = 1，nextIndex++ 进入 下 一 个 节点 的 判断 。 
口 从 新 集合 中 取得 D,， 然后 判断 旧 集合 中 是 否 存在 相同 节点 D， 此 时 发 现存 在 节点 D, 接着 
















































































通过 对 比 节点 位 置 判断 是 否 进行 移动 操作 。D 在 旧 集合 中 的 位 置 D._mountIndex = 3， 此 


时 LastIndex = 1， 不 满足 child._mountIndex < LastIndex 的 条 件 ， 因 此 不 对 D 进行 移 
动 操 作 。 更 新 LastIndex = Math.max(prevChild._mountIndex, lastIndex)， 则 LastIndex = 
3， 并 将 DD 的 位 置 更 新 为 新 集合 中 的 位 置 prevChiLd. mountIndex = nextIndex， 此 时 新 集 














合 中 D._mountIndex = 2，nextIndex++ 进入 下 一 个 节点 的 判断 。 


























口 从 新 集合 中 取得 C， 然 后 判断 旧 集合 中 是 否 存在 相同 节点 C， 此 时 发 现存 在 节点 C， 接 着 











通过 对 比 节点 位 置 判 断 是 否 进 行 移动 操作 。C 在 旧 集合 中 的 位 置 
时 LastIndex = 3， 满 足 child._mountIndex < LastIndex 的 条 件 ， 




















enqueueMove(this, child._mountIndex, toIndex)。 更 新 LastIndex = Math.max(prevChild. 
_mountIndex，LastIndex) ， 则 LastIndex = 3， 并 将 C 的 位 置 更 新 为 新 集合 中 的 位 置 

















因此 对 C 进行 移动 操 





C._mountIndex = 2， 此 


作 





prevChiLd._mountIndex = nextIndex ， 此 时 新 集合 中 A._mountIndex = 3，nextIndex++ 进 
和 人 下 一 个 节点 的 判断 。 由 于 C 已 经 是 最 后 一 个 节点 ， 因 此 di 人 操作 到 此 完成 。 
上 面 主要 分 析 新 旧 集 合 中 存在 相同 节点 但 位 置 不 同时 , 对 节点 进行 位 置 移动 的 情况 。 如 果 新 


















































集合 中 有 新 加 入 的 节点 且 旧 集合 存在 需要 删除 的 节点 ， 那么 diff 又 是 如 何 对 比 运作 的 呢 ? 
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下 面 以 图 3-23 为 例 进行 介绍 。 

口 从 新 集合 中 取得 B， 然 后 判断 旧 集 合 中 存在 是 否 相 同 节 点 B， 可 以 发 现存 在 节点 B。 由 于 
B 在 旧 和 集合 中 的 位 置 B._mountIndex = 1， 此 时 LastIndex = 0， 因 此 不 对 B 进行 移动 操作 。 
更 新 LastIndex = 1, 并 将 B 的 位 置 更 新 为 新 集合 中 的 位 置 B._mountIndex = 0，nextIndex++ 
进入 下 一 个 节点 的 判断 。 

口 从 新 集合 中 取得 E， 然 后 判断 旧 和 集合 中 是 否 存 在 相同 节点 E， 可 以 发 现 不 存在 ， 此 时 可 以 
创建 新 节点 卫 。 更 新 LastIndex = 1， 并 将 E 的 位 置 更 新 为 新 集合 中 的 位 置 ，nextIndex++ 
进入 下 一 个 节点 的 判断 。 

口 从 新 集合 中 取得 C， 然 后 判断 旧 集 合 中 是 否 存在 相同 节点 C， 此 时 可 以 发 现存 在 节点 C。 
由 于 C 在 旧 和 集合 中 的 位 置 C._mountIndex = 2，lastIndex = 1， 此 时 C._mountIndex > 
LastIndex， 因 此 不 对 C 进行 移动 操作 。 更 新 LastIndex = 2， 并 将 C 的 位 置 更 新 为 新 集 
合 中 的 位 置 ，nextIndex++ 进入 下 一 个 节点 的 判断 。 

口 从 新 集合 中 取得 A， 然后 判断 旧 集 合 中 是 否 存在 相同 节点 A， 此 时 发 现存 在 节点 A。 由 于 
A 在 旧 和 集合 中 的 位 置 A._mountIndex =0，LastIndex = 2， 此 时 A._mountIndex < LastIndex， 
因此 对 A 进行 移动 操作 。 更 新 LastIndex = 2， 并 将 A 的 位 置 更 新 为 新 集合 中 的 位 置 ， 
nextIndex++ 进入 下 一 个 节点 的 判断 。 

口 当 完 成 新 集合 中 所 有 节点 的 差异 化 对 比 后 ， 还 需要 对 旧 集合 进行 循环 遍历 ， 判 断 是 否 存 
在 新 集合 中 没有 但 旧 集 合 中 仍 存 在 的 节点 ,此 时 发 现存 在 这 样 的 节点 D ,因此 删除 节点 D， 
到 此 di 企 操 作 全 部 完成 。 






























































































































































key=b key=e key=d key=a 
图 3-23 创建、 移动、 删除 节点 
相关 代码 如 下 源码 路 径 : /v15.0.0/src/renderers/shared/reconciler/ReactMultiChild.js ): 





_updateChildren: function(nextNestedChildrenElements, transaction, context) { 

var prevChildren = this._renderedChildren; 

var removedNodes = {}; 

var nextChildren = this._reconcilerUpdateChildren(prevChildren, nextNestedChildrenElements, 
removedNodes, transaction, context); 


// 如 果 不 存 在 prevChildren 和 nextChildren， 则 不 做 diff 处 理 
if (!nextChildren && !prevChildren) { 
return; 


} 


3.5 ” diff 算法 
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var Updates = null; 

var Name; 

// LastIndex 是 prevChildren 中 最 后 的 索引 ，nextIndex 是 nextChildren 中 每 个 节点 的 索引 
var LastIndex = 0; 

var nextIndex = 0; 

var LastPLacedNode = null; 


for (name in nextChildren) { 
if (!nextChildren.hasOwnProperty(name)) { 
continue; 
} 
var prevChild = prevChildren && prevChildren[name]; 
var nextChild = nextChildren[name]; 
if (prevChild === nextChild) { 
// 移动 节点 
updates = enqueue( 
Updates， 
this.moveChild(prevChild, lastPlacedNode, nextIndex, lastIndex) 
); 
LastIndex = Math.max(prevChild. mountIndex, lastIndex); 
prevChild. mountIndex = nextIndex; 
} elsef{ 
if (prevChild) { 
LastIndex = Math.max(prevChild. mountIndex, lastIndex); 
// 通过 遍历 removedNodes 删除 子 节点 prevChild 
} 
// 初始 化 并 创建 节点 
updates = enqueue( 


Updates， 
this._mountChiLdAtIndex(nextChiLd，LastPLacedNode，nextIndex，transaction，CcContext) 
); 
} 
nextIndex++; 
LastPLacedNode = ReactReconciler .getNativeNode(nextChild); 


} 
// 如 果 父 节点 不 存在 ， 则 将 其 子 节点 全 部 移 除 
for (name in removedNodes) { 
if (removedNodes.hasOwnProperty(name)) { 
updates = enqueue( 
Updates， 
this._unmountChiLd(prevChiLdren[name] ，removedNodes[name]) 
); 
二 
} 
// 如 果 存 在 更 新 ， 则 处 理 更 新 队列 
if (updates) { 
processQueue(this, updates); 
} 


this._renderedChildren = nextChildren; 


于 


function enqueue(queue, update) { 
// 如 果 有 更 新 ， 将 其 存 入 queue 
if (update) { 
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queue = queue || 口 ; 
queue.push(update); 
} 
return queue; 


} 


// 处 理 队列 的 更 新 
function processQueue(inst, updateQueue) { 
ReactComponentEnvironment.processChildrenUpdates( 


inst, 
updateQueue, 
); 

} 

// 移动 节点 


moveChild: function(child, afterNode, toIndex, lastIndex) { 
// 如 果子 节点 的 index 小 于 LastIndex， 则 移动 该 节点 
if (child. mountIndex < LastIndex) { 
return makeMove(child, afterNode, toIndex); 
} 
}， 


// 创建 节点 
createChild: function(child, afterNode, mountImage) { 
return makeInsertMarkup(mountImage, afterNode, child. mountIndex); 


}， 


// 删除 节点 
removeChild: function(child, node) { 
return makeRemove(child, node); 


}， 


// 趣 载 已 经 澄 染 的 子 节点 

_unmountChild: function(child, node) { 
var Update = this.removeChild(child, node); 
child. _ mountIndex = null; 
return update; 


}， 


// 通过 提供 的 名 称 实例 化 子 节点 
_mountChiLdAtIndex: function(child, afterNode, index, transaction, context) { 
var mountImage = ReactReconciler .mountComponent(child, transaction, this, this._nativeContainerInfo, 
context); 


chiLd._mountIndex = index; 
return this.createChild(child, afterNode, mountImage); 


}, 
当然 ，diff 还 存在 些许 不 足 与 待 优 化 的 地 方 。 如 图 3-24 所 示 , 和 若 新 集合 的 节点 更 新 为 D、 
B、C，, 与 旧 集 合 相 比 只 有 DD 节点 移动 ， 而 A、B、C 仍然 保 持原 有 的 顺序 ， 理 论 上 diff 应 该 只 需 
对 D 执行 移动 操作 ， 然 而 由 于 D 在 旧 和 集合 中 的 位 置 是 最 大 的 ， 导 致 其 他 节点 的 _mountIndex < 

LastIndex， 造 成 D 没有 执行 移动 操作 ， 而 是 A、B 、C 全 部 移动 到 D 节点 后 面 的 现象 。 
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key=d key=a key=b key=c 








图 3-24 ”新 集合 的 节点 更 新 为 D、A、B、C 





建议 在 开发 过 程 中 ， 尽 量 减少 类 似 将 最 后 一 个 节点 移动 到 列表 首部 的 操作 。 当 节点 数量 过 大 Sl 
或 更 新 操作 过 于 频繁 时 ， 这 在 一 定 程度 上 会 影响 React 的 泻 染 性 能 。 





3.6 ”React Patch 方法 


通过 前 面 的 内 容 ， 我 们 了 解 了 React 如 何 构 建 虚拟 标签 ， 执 行 组 件 生 命 周 期 ， 更 新 state， 计 
算 tree diff 等 ， 这 一 系列 操作 都 还 是 在 Virtual DOM 中 进行 的 。 然 而 浏览 器 中 并 未 能 显示 出 更 新 
的 数据 ， 那 么 React 又 是 如 何 让 浏览 器 展示 出 最 新 的 数据 呢 ? 


React Patch 实现 了 关键 的 最 后 一 步 。 所 谓 Patch， 简 而 言 之 就 是 将 tree diff 计算 出 来 的 DOM 
差异 队列 更 新 到 真实 的 DOM 节点 上 ， 最 终 让 浏览 器 能 够 演 染 出 更 新 的 数据 。 可 以 这 么 说 ， 如 果 
没有 Patch,， 那么 React 之 前 基于 Virtual DOM 做 再 多 性 能 优化 的 操作 都 是 徒劳 ， 因 为 浏览 器 并 不 
认识 Virtual DOM。 虽 然 Patch 方法 如 此 重要 ， 但 它 的 实现 却 非常 简洁 明了 ， 主 要 是 通过 遍历 差 
异 队列 实现 的 。 遍 历 差异 队列 时 ,通过 更 新 类 型 进行 相应 的 操作 ,包括 : 新 节点 的 插入 、 已 有 节 
点 的 移动 和 移 除 等 。 

这 里 为 什么 可 以 直接 依次 插入 节点 呢 ? 原因 就 是 在 di 在 阶段 添加 差异 节点 到 差异 队列 时 , 本 
身 就 是 有 序 添 加 。 也 就 是 说 , 新 增 节 点 (包括 move 和 insert ) 在 队列 里 的 顺序 就 是 最 终 真实 DOM 
的 顺序 ， 因 此 可 以 直接 依次 根据 index 去 搬 和 节点。 而且，React 并 不 是 计算 出 一 个 差异 就 去 执 
行 一 次 Patch， 而 是 计算 出 全 部 差异 并 放 人 差异 队列 后 ， 再 一 次 性 地 去 执行 Patch 方法 完成 真实 
DOM 的 更 新 。 

Patch 方 法 的 源码 如 下 (源码 路 径 : /v15.0.0/src/renderers/dom/client/utils/DOMChildren- 
Operations.js ): 















































































































































processUpdates: function(parentNode, updates) { 
// 处 理 新 增 的 节点 、 移 动 的 节点 以 及 需要 移 除 的 节点 
for (var k = 0; k < updates.Length; k++) { 
var update = updates[k]; 
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switch (update.type) { 
// 插入 新 的 节点 
case ReactMultiChildUpdateTypes.INSERT_MARKUP: 
insertLazyTreeChiLdAt( 
parentNode, 
update.content, 
getNodeAfter(parentNode, update.afterNode) 
); 
break; 
// 需要 移动 的 节点 
case ReactMultiChildUpdateTypes.MOVE_EXISTING: 
moveChild( 
parentNode, 
update.fromNode, 
getNodeAfter(parentNode, update.afterNode) 
); 
break; 
case ReactMultiChildUpdateTypes.SET_MARKUP: 
setInnerHTML( 
parentNode, 
update.content 
); 
break; 
case ReactMultiChildUpdateTypes.TEXT_CONTENT: 
setTextContent( 
parentNode, 
update.content 
); 
break; 
// 需要 删除 的 节点 
case ReactMultiChildUpdateTypes .REMOVE_NODE: 
removeChild(parentNode, update.fromNode); 
break; 
} 
}， 


function getNodeAfter(parentNode, node) { 
// 文本 组 件 的 返回 格式 [open，close] comments， 需 要 做 特殊 处 理 
if (Array.isArray(node)) { 
node = node[1]; 
} 
return node ? node.nextSibling : parentNode.firstChild; 


} 
// 插入 新 节点 的 操作 


function insertLazyTreeChildAt(parentNode, childTree, referenceNode) { 
DOMLazyTree.insertTreeBefore(parentNode, childTree, referenceNode); 


} 
// 移动 已 有 节点 的 操作 


function moveChild(parentNode, childNode, referenceNode) { 
if (Array.isArray(childNode)) { 
moveDelimitedText(parentNode, childNode[0], childNode[1], referenceNode); 
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} elLse { 
insertChildAt(parentNode, childNode, referenceNode); 


} 
} 
// 移 除 已 有 节点 的 操作 


function removeChild(parentNode, childNode) { 
if (Array.isArray(childNode)) { 
var closingComment = childNode[1]; 
childNode = childNode[0]; 
removeDelimitedText(parentNode, childNode, closingComment); 
parentNode.removeChild(closingComment); 


} 


parentNode.removeChild(childNode); 


} 


// 文本 组 件 需要 去 除 openingComment 和 closingComment， 取 得 其 中 的 node 
function moveDelimitedText(parentNode, openingComment, closingComment, referenceNode) { 


var node = openingComment; 


while (true) { 
var nextNode = node.nextSibling; 
insertChildAt(parentNode, node, referenceNode); 

if (node === closingComment) { 


break; 


node = nextNode; 
function removeDelimitedText(parentNode, startNode, closingComment) { 


} 


} 


， 


var node = startNode.nextSibling; 


while (true) { 
if (node === closingComment) { 
// closingComment 已 经 被 ReactMultiChild 移 除 





、setState 更 新 机 制 、 








break; 
} elLse 
parentNode.removeChild(node); 





} 


本 章 主要 分 析 了 React 源码 中 Virtual DOM 模型 、 组 件 生命 周期 的 管理 
diff 算法 以 及 Patch 方法 。 正 因为 React 有 着 这 样 独特 的 设计 ， 才 让 它 站 在 了 今天 前 端 大 舞台 的 


} 


3 


3.7 小 结 
>a 
在 本 章 写 作 的 过 程 中 ，React 15.0 版 本 又 进行 了 几 次 小 版 本 


除了 本 章 分 析 的 核心 方法 , React 还 有 许多 优秀 的 实现 ， 比 如 对 象 生成 时 内 存 的 线程 池 管 理 、 
尼 React Fiber， 和 希望 读者 自行 阅读 源码 分 析 其 实现 原理 。 


聚光灯 下 。 
件 系统 的 优化 、 服 务 端的 泻 染 等 。 
的 更 新 ， 还 发 表 了 多 年 的 研究 成 
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认识 Flux 染 构 模式 














Flux 是 由 Facebook 在 2014 年 开源 的 一 款 用 于 构建 用 户 界 面 的 应 用 程序 架构 ( Application 
Architecture for Building User Interface )。 随 着 师 出 同门 的 React 越 来 越 火爆 ，Flux 也 受到 了 越 来 
越 多 的 关注 。 

那么 ,Flux 究 竞 是 怎么 一 回 事 呢 ?Flux 与 我 们 常 说 的 前 端 MVC 架构 有 什么 区 别 呢 ? 我 们 将 
在 本 章 中 一 起 探索 。 


























4.1 React 独立 架构 


在 第 1 章 中 ， 我们 就 提 到 React 是 自 带 View 和 Controller 的 库 。 自 然 ， 我 们 在 实现 应 用 时 不 
需要 任何 其 他 库 也 可 以 自 运行 。 

为 了 更 好 地 理解 从 React 到 React+Flux 的 演进 路 线 ， 我 们 就 以 前 几 章 学 习 的 内 容 来 实现 一 个 
类 似 论坛 评论 功能 的 App， 从 而 开始 讲述 实际 应 用 中 的 实现 过 程 。 

首先 ， 我 们 先 看 评论 功能 包括 哪些 部 分 。 基 本 的 评论 功能 由 以 下 两 个 部 分 组 成 : 
口 评论 内 容 区 域 ， 它 是 一 个 从 服务 端 读 取 的 列表 ， 每 一 条 评论 都 包括 用 户 名 、 时 间 和 内 容 ; 
口 评论 编辑 区 域 ， 除 了 显示 自己 的 用 户 名 外 ， 需 要 一 个 待 编辑 的 文本 框 以 及 “发 布 ”按钮 。 


对 于 评论 的 基本 逻辑 ,我 相信 你 早 就 熟悉 了 。 简 而 言 之 ， 就 是 输入 评论 内 容 之 后 , 点击“ 发 
布 ”按钮 发 布 评论 ， 此 时 评论 就 会 立即 显示 在 评论 区 内 。 


接 下 来 ， 我 们 就 用 React 来 实现 它 。 


首先 ， 需 要 约定 前 后 端 接 口 。 这 里 我 们 新 建 /apiresponse.json， 用 于 模拟 一 个 返回 评论 列表 
的 接口 : 


{ 
"commentList": [ 
{ "name": "cam", "content": "It's good idea!", "publishTime": "2015-05-01" }, 
{ "name": "arcthur", "content": "Not bad.", "publishTime": "2015-05-01" } 
] 
} 
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接着 ， 写 一 个 React 组 件 用 于 读 取 评 论 列 表 : 
import React, { Component, PropTypes } from 'react'; 


class CommentList extends Component { 
constructor(props) { 
super(props); 


this.state = { 
loading: true, 
error: null, 
value: null, 
}; 
3} 


componentDidMount() { 
this.props.promise.then(response => response.json()) 
.then(vatLue => this.setState({ loading: false, value })) 
.Catch(error => this.setState({ loading: false, error })); 


} 


render() { 
if (this.state.loading) { 
return <span>Loading...</span>; 





} else if (this.state.error !== null) { 
return <span>Error: {this.state.error.message}</span>; 
} else{ 


const list = this.state.valuye.commentList; 


return ( 
<ul className="comment-box"> 
{list.map((entry, i) => ( 
<li key={ “reponse-${i}.} className="comment-item"> 
<p className="comment-item-name">{entry.name}</p> 
<p className="comment-item-content">{entry.content}</p> 
</li> 
))} 
</ul> 
); 
} 
} 
} 


ReactDOM. render( 
<CommentList promise={fetch('/api/response.json')} />， 
document .getELementById('root ' )); 


看 一 下 这 个 组 件 构 成 ,可 以 发 现 它 把 数据 请 求 与 业务 逻辑 混合 在 了 一 起 。 显 然 , 业务 逻辑 不 
需要 关心 数据 是 从 哪里 来 的 ， 只 需要 定义 好 传人 的 接口 就 行 了 ， 数 据 应 该 抽象 到 其 他 地 方 去 做 。 
为 了 不 引入 更 多 概念 ,把 数据 请 求 抽 象 到 父 组 件 中 。 含 有 抽象 数据 而 没有 业务 逻辑 的 组 件 , 我 们 
称 之 为 容器 型 组 件 ( container component ); 而 没有 数据 请 求 逻 辑 只 有 业务 逻辑 的 组 件 ， 我 们 称 之 
为 展示 型 组 件 ( presentational component )。 在 5.5 节 中 ， 我 们 会 综合 讲述 两 者 的 不 同意 义 。 























186 第 4 章 认识 Flux 架构 模式 





说 明 请 求 部 分 使 用 fetch API， 这 是 由 WHATWG ( Web Hypertext Application Technology 
Working Group ， 网 页 超 文本 应 用 技术 工作 小 组 ) 提出 的 新 一 代 浏 览 器 Ajax 请 求 标准 ， 
目前 已 经 获得 了 主流 浏览 器 的 支持 。 新 版 本 的 Chrome、Firefox 和 人 浏览 器 均 支 持 
fetch API， 而 微软 的 Edge 浏览 器 也 正在 开发 对 fetch 的 支持 。 
fetch 的 用 法 相 比 于 原始 的 XMLHttpRequest 有 着 质 的 飞跃 ， 比 如 : 


fetch('/user.json').then(response => response.json()) 
.then(data => console.log('parsed json', data)) 
.Catch(e => console.log("O0ops, error", e)); 


fetch 的 主要 特点 是 运用 promise 来 对 请 求 作 了 包装 ， 其 语法 非常 简 洁 ， 具有 语义 化 。 
考虑 到 兼容 比较 旧 的 浏览 器 ， 我 们 可 以 使 用 GitHub 官方 提供 的 fetch 7 更 多 关于 
fetch 的 信息 ， 可 以 参考 WHATWG 的 fetch 规范 "。 


接着 ,我 们 就 来 改造 一 下 。 抽 象 CommentListContainer 组 件 : 
import React, { Component, PropTypes } from 'react'; 


class CommentListContainer extends Component { 
constructor(props) { 
super (props); 


this.state = { 
loading: true, 
error: null, 
value: null, 
}; 
} 


componentDidMount() { 
this.props.promise.then(response => response.json()) 
.then(value => this.setState({ loading: false, value })) 
.Catch(error => this.setState({ loading: false, error })); 


} 


render() { 
if (this.state.loading) { 
return <span>Loading...</span>; 
} else if (this.state.error !== null) { 
return <span>Error: {this.state.error.message}</span>; 
} else { 
const list = this.state.value.commentList; 


return ( 
<CommentList comments={list} /> 
); 
} 





GD Fetch Living Standard， 详 见 https://fetch.spec.whatwg.org。 
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} 
} 


然后 我 们 的 业务 逻辑 就 变 得 非常 轻 量 级 。 用 无 状态 组 件 即 可 实现 
import React, { Component, PropTypes } from 'react'; 


function CommentList({ comments }) { 
return ( 
<UL className="comment-box"> 
{comments.map((entry, i) => ( 
<li key={ reponse-${i} } className="comment-item"> 
<p className="comment-item-name">{entry.name}</p> 
<p className="comment-item-content">{entry.content}</p> 
</li> 
))} 
</ul> 
); 
} 





， 此 时 代码 变 得 非常 简洁 : 


再 来 看 下 请 求 的 容器 组 件 , 是 否 看 到 了 很 多 重复 代码 的 痕迹 ? 异步 请 求 的 过 程 每 个 组 件 都 有 











可 能 存在 ， 因 此 不 得 不 写 很 多 重复 代码 。 当 然 ， 这 个 过 程 可 以 被 抽象 
绍 的 方便 提取 组 件 的 “公共 行为 "， 让 组 件 可 以 进一步 抽象 


import React, { Component, PropTypes } from 'react'; 


function dissoc(obj, prop) { 
let result = {}; 


for (let p in obj) { 
if (p !== prop) { 
resuLt[p] = obj[p]; 
} 
} 


return result; 


和 


const Promised = (promiseprop, Wrapped) => class extends Component { 
constructor(props) { 
super(props); 


this.state = { 
loading: true, 
error: null, 
value: null, 
}; 
} 


componentDidMount() { 
this.props[promiseprop].then(response => response.json()) 
.then(vatLue => this.setState({ loading: false, value })) 
.Catch(error => this.setState({ loading: false, error })); 
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render() { 
if (this.state.loading) { 
return <span>Loading...</span>; 


} else if (this.state.error !== null) { 
return <span>Error: {this.state.error.message}</span>; 
} else { 


const propsWithoutThePromise = dissoc(this.props, promiseprop); 
return <Wrapped {...propsWithoutThePpromise} {...this.state.value} />; 
} 
} 
}; 








正如 看 到 的 , 通过 把 组 件 传递 给 Promised，, 就 可 以 实现 一 个 具有 请 求 功能 的 组 件 了 。 我 们 把 


CommentListContainer 组 件 输出 的 方式 改造 一 下 即 可 : 
py 


class CommentListContainer extend Component{ 
render() { 
return <CommentList data={data} />; 
} 
上 


module.exports = Promised('comments', CommentListContainer); 
此 时 就 可 以 这 么 调用 它 


ReactDOM. render(<CommentListContainer comments={fetch('/api/response.json')} />， 
document .getElementById('root')); 





看 到 CommentListContainer 与 CommentList 其 经 等 同 了 ， 这 时 候 可 以 选择 合并 了 

















保留 的 意义 在 于 如 果 未 来 数据 是 由 多 个 请 求 合并 0 那么 在 CommentListContainer 的 多 香 
就 不 能 通过 Promised 高 阶 组 件 解 决 了 。 换 句 话说 ， 容 需 型 组 件 更 通用 ， 而 Promised 是 一 种 取 巧 











且 抽象 的 方法 ， 可 以 依 情况 而 定 。 
到 这 里 ,我 们 已 经 实现 了 对 列表 的 展示 。 除 了 列表 的 请 求 泻 染 ， 自 el 
































的 评论 操作 包括 一 个 评论 框 和 一 个 “提交 ”按钮 。 当 然 ， 现实 中 的 评论 会 复杂 很 多 ， 比 如 级 联 。 





这 里 我 们 只 关注 最 简单 的 情况 ， 相 关 代 码 如 下 : 


import React, { Component, PropTypes } from 'react'; 





class CommentForm extends Component { 
constructor(props) { 
super (props); 


this.handleChang = this.handleChange.bind(this); 


this.state = { 
value: ''， 
}; 
} 
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handleChange(event) { 
this.setState({ vaLue: event.target.value }); 


} 


render() { 
return ( 
<div> 
<textarea 
value={this.state.value} 
onChange={this.handLeChange} 
/> 
<button 
className="comment-confirm-btn" 
onClick={this.props.onSubmitComment.bind(this, this.state.value)} 
> 评论 </button> 
</div> 
); 
} 
} 


这 个 过 程 很 简单 ， 我 们 放 了 一 个 textarea 和 button。 请 你 仔细 想 想 ， 提 交 的 行为 为 什么 没有 
在 组 件 里 实现 ， 而 是 放 在 父 组 件 里 。 最 后 ， 需 要 把 CommentListContainer 和 CommentForm 这 两 
个 组 件 合 在 一 起 : 


import React, { Component, PropTypes } from 'react'; 





class CommentBox extends Component { 
constructor(props) { 
super(props); 


this.state = { 
comments: fetch('/api/response.json'), 
}; 
. 


handleSubmitComment(value) { 
fetch('/api/submit.json', { 
method: 'POST', 
body: ‘value=${value}, 
}) 
.then(response => response.json()) 
.then(vaLue => { 
if (value.ok) { 
this.setState({ comments: fetch('/api/response.json') }); 
} 
DD)); 
} 


render() { 

return ( 

<div> 
<CommentListContainer comments={this.state.comments} /> 
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<CommentForm onSubmitComment={::this.handleSubmitComment} /> 
</div> 
); 
} 
} 


ReactDOM. render(<CommentBox />, document.getElementById('root')); 

上 述 代 码 模拟 了 一 个 POST 请求 用 于 提交 评论 ， 这 里 没有 提交 用 户 信息 。 这 是 一 个 问题 , 读 
者 可 以 思考 一 下 怎么 去 完整 实现 。 

评论 功能 到 这 里 总 体 上 就 完成 了 ， 这 个 实现 告诉 我 们 ，React 可 以 通过 抽象 “容器 型 组 件 ” 
来 集成 Model 的 功能 。 
日 这 么 做 还 是 把 业务 逻辑 整合 到 了 组 件 当中 , 这 并 不 是 最 优 的 方法 , 与 数据 逻辑 解 耦 才 是 我 
们 所 期 望 的 。 在 大 型 应 用 中 ， 数 据 和 状态 管理 至 关 重 要 。 我 们 想 用 这 几 年 风靡 前 端 界 的 MVC 思 
想来 实现 ， 这 当然 可 以 , 但 Facebook 告诉 我 们 还 有 一 种 新 的 Flux 架构 ， 它 才 是 React Web app 应 
有 的 姿态 。 那 么 ,在 Flux 中 到 底 是 怎么 做 的 ?下 面 我 们 来 一 探究 竞 。 





























4.2 MV* 与 Flux 


响应 式 网 页 设计 (Responsive Web design ) "简称 RWD, 是 2011 年 提出 的 概念 , 并 从 2012 年 
开始 成 为 公认 的 网 页 设计 主流 方向 。 它 是 一 种 网 页 设计 的 技术 做 法 , 该 设计 可 使 网 站 在 多 种 浏览 
设备 (从 台式 机 显示 器 到 移动 电话 或 其 他 移动 产品 设备 ) 上 获得 体验 类 似 的 阅读 与 导航 功能 ， 同 
时 减少 用 户 缩放 、 和 平移 与 滚动 等 操作 

这 就 要 求 网 站 需要 设计 成 SPA ( Single-Page Application， 单 页 应 用 )。 尽 管 说 响应 式 网 页 设 
计 的 核心 理念 是 从 交互 以 及 样式 上 体现 的 , 但 对 于 整个 跨 平 台 的 兼容 性 , 拥有 良好 的 分 层 解 而 及 
响应 速度 已 经 成 为 应 用 架构 的 必要 条 件 。 

而 这 之 中 ， 以 BackboneJS 、AngularJS 为 代表 的 MVC/MVVM 和 Flux 渐渐 成 为 了 主流 选择 。 
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4.2.1 MVC/MVVM 
MVC/MVVM 简称 MC* 模式 ， 其 中 MVVM 是 从 MVC 演进 而 来 的 。 要 理解 这 之 间 的 关系 ， 
还 得 从 MVC 的 概念 说 起 。 
MVC 是 一 种 架构 设计 模式 ， 它 通过 关注 数据 界面 分 离 ， 来 鼓励 改进 应 用 程序 结构 。 有 具体 地 
说 ，MVC 强制 将 业务 数据 ( Model ) 与 用 户 界 面 (View ) 隔离 ， 用 控制 器 ( Controller ) 管理 逻 
辑 和 用 户 输入 。 这 种 模式 是 Smalltalk 在 20 世纪 80 年 代 研 究 设计 出 来 的 ， 如 图 4-1 所 示 。 


















































CD Responsive Web design， 详 见 https://en.wikipedia.org/wiki/Responsive web design。 
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用 户 输入 


View 更 新 Controller 
i 
展现 输出 


UI， 展 现 当前 model 状态 传递 而 应 为 View 作 决 定 












[eg 
TEL 





| Model | 
特定 领域 的 数据 
图 4-1 MVC 模 型 


1. MVC 模式 中 的 3 种 角色 

在 MVC 模 式 中 , 主要 涉及 3 种 角色 一 Model、View 和 Controller, 下 面 简要 介绍 一 下 它们 。 
© Model 

Model 负责 保存 应 用 数据 ， 和 后 端 交互 同步 应 用 数据 ， 或 校 验 数据 。 


Model 不 涉及 用 户 界面 ， 也 不 涉及 表示 层 ， 而 是 代表 应 用 程序 可 能 需要 的 独特 形式 的 数据 。 
当 Model 改变 时 ， 它 会 通知 它 的 观察 者 (如 视图 ) 作出 相应 的 反应 。 


总 的 来 说 ，Model 主要 与 业务 数据 有 关 ， 与 应 用 内 交互 状态 无 关 。 


@ View 
View 是 Model 的 可 视 化 表示 , 表示 当前 状态 的 视图 。 前端 View 负责 构建 和 维护 DOM 元 素 。 
View 对 应 用 程序 中 的 Model 和 Controller 的 了 解 是 有 限 的 ， 更 新 Model 的 实际 任务 都 是 在 
Controller 上 。 
用 户 可 以 与 View 交互 ， 包 括 读 取 和 编辑 Model， 在 Model 中 获取 或 设置 属性 值 。 
一 个 View 通常 对 应 一 个 Model， 并 在 Model 更 改 时 进行 通知 , 使 View 本 身 能 够 进行 相应 的 
更 新 。 但 在 实际 应 用 开发 中 ， 还 会 面临 多 个 View 对 应 多 个 Model 的 情况 。 
在 前 端 MVC 体系 中 ，View 对 应 的 是 JavaScript 模板 语言 ， 它 用 于 将 View ， A 
变量 的 标记 ， 使 用 变量 语法 ， 接 受 JSON 数据 格式 的 数据 。 而 React 本 身 具 备 模 板 这 一 特性 ， 
点 在 第 1 时 章 中 已 经 提 过 0 


@ Controller 

负责 连接 View 和 Model, Model 的 任何 改变 会 应 用 到 View 中 , View 的 操作 会 通过 Controller 
应 用 到 Model 中 。 

在 前 端 MVC 框架 中 ，Controller 的 设计 和 传统 MVC 中 的 概念 还 是 不 太一 样 。 如 Backbone， 
包含 Model 和 View， 但 它 实际 上 并 没有 真正 的 Controller。 其 View 和 路 由 的 行为 与 Controller 有 
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些 类 似 ， 但 它们 实际 上 都 不 是 Controller. 
总 的 来 说 ，Controller 管理 了 应 用 程序 中 Model 和 View 之 间 的 逻辑 和 协调 。 
2. MVVM 的 演变 


MVVM 出 现 于 2005 年 , 最 大 变化 在 于 VM ( ViewModel ) 代替 了 C ( Controller ), 其 关键 “ 改 
进 ” 是 数据 绑 定 (DataBinding )， 也 就 是 说 ，View 的 数据 状态 发 生变 化 可 以 直接 影响 VM， 反 之 
亦 然 。 这 也 可 以 说 是 AngularJS 的 核心 特色 之 一 。MVVM 模型 如 图 4-2 所 示 。 
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图 4-2 MVVM 模型 


3. MVC 的 问题 

MVC 乍 一 看 似乎 没有 特别 值得 诉 病 的 地 方 ， 但 是 它 存在 一 个 致命 的 缺点 ， 这 个 缺点 在 你 
的 项 目 越 来 越 大 、 逻 辑 越 来 越 复杂 的 时 候 就 非常 明显 ， 那 就 是 混乱 的 数据 流动 方式 ， 如 图 4-3 
所 示 。 
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图 4-3 ”MVC 的 问题 








以 Backbone 为 例 ， 由 于 Model 对 外 直接 暴露 了 set 和 on 方法 ， 导 致 View 层 可 以 随意 改变 
Model 中 的 值 ， 也 可 以 随意 监听 Model 中 值 的 变化 。 这 样 的 设 定 最 终 会 导致 一 个 庞大 的 Model 中 
某 个 字段 变化 后 ,可 能 触发 无 数 个 change 事件 。 在 这 些 change 事件 的 回调 中 , 可 能 还 有 新 的 set 
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方法 调用 ， 导 致 更 多 的 change 事件 触发 。 

更 糟糕 的 是 ， 一 个 Model 还 能 改变 另 一 个 Model 的 值 ， 整 个 数据 流动 的 方式 变 得 更 加 混乱 ， 
不 可 捉摸 。 可 以 预见 ， 在 这 种 复杂 的 监听 和 触发 的 关系 中 ,梳理 数据 的 流动 方式 ， 甚 至 调试 业务 
逻辑 都 成 了 一 种 奢望 。 

对 于 增 、 删 、 改 来 说 ，MVC 都 需要 编写 View 泻 染 处 理 函 数 。 当 业务 逻辑 变 复杂 后 ， 可 能 
有 很 多 Model 需要 做 增 、 删 、 改 。 与 之 对 应 的 是 ， 我 们 需要 精心 构建 View 尝 染 处 理 函 数 。 尽 
局 部 更 新 模式 是 高 性 能 的 关键 所 在 , 但 这 点 会 导致 更 新 逻辑 复杂 , 并 需要 编写 大 量 的 局 部 泻 染 
数 ， 也 会 导致 问题 定位 困难 。 页 面 的 当前 状态 是 由 数据 和 局 部 更 新 图 数 来 确定 的 。 

在 实际 应 用 中 , 前 端 MVC 模式 的 实现 各 有 各 的 理解 。 在 Google Images 中 搜索 “前 端 MVC”， 
从 得 到 的 结果 可 以 看 到 ， 几 乎 每 个 人 对 Model、View 和 Controller 都 有 自己 的 理解 ， 而 它们 之 间 
的 连 线 更 是 千奇百怪 。 

4. 解决 方案 

如 果 泻 染 函 数 只 有 一 个 ， 统 一 放 在 Controller 中 ， 每 次 更 新 重 泻 染 页 面 ， 这 样 的 话 ， 任 何 数 
据 的 更 新 都 只 用 调用 重演 染 就 行 , 并 且 数 据 和 当前 页 面 的 状态 是 唯一 确定 的 。 这 样 又 要 保证 数据 
的 流动 清晰 ， 不 能 出 现 交 叉 分 路 的 情况 。 

然而 重演 染 会 带 来 严重 的 性 能 与 用 户 体 验 问题 。 重 演 染 和 局 部 泻 染 各 有 好 坏 ， 对 MVC 来 说 

是 一 个 两 难 的 选择 ， 无 法 做 到 鱼 和 能 掌 兼 得 。 
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4.2.2 Flux 的 解决 方案 


与 React 相同 ，Flux 同样 由 一 群 Facebook 工程 师 提 出 ， 它 的 名 字 是 拉丁 语 的 Flow。Flux 的 
提出 主要 是 针对 现 有 前 端 MVC 框架 的 局 限 总 结 出 来 的 一 套 基于 dispatcher 的 前 端 应 用 架构 模 
式 。 如 果 用 MVC 的 命名 习惯 ， 它 应 该 叫 ADSV ( Action Dispatcher Store View )。 

那么 Flux 是 如 何 解 决 MVC 存在 的 问题 呢 ? 正如 其 名 ，Flux 的 核心 思想 就 是 数据 和 逻辑 永 
远 单 向 流动 。 其 模型 图 如 图 4-4 所 示 。 
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Dispather 


图 4-4 Flux 模型 


在 介绍 React 的 时 候 ， 我 们 也 提 到 它 推崇 的 核心 也 是 单 向 数据 流 ，Flux 中 单 向 数据 流 则 是 在 
整体 架构 上 的 延伸 。 在 Flux 应 用 中 ， 数 据 从 action 到 dispatcher， 再 到 store， 最 终 到 view 的 路 
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线 是 单 向 不 可 逆 的 ， 各 个 角色 之 间 不 会 像 前 端 MVC 模式 中 那样 存在 交错 的 连 线 。 

然而 想 要 做 到 单 向 数据 流 ， 并 不 是 一 件 容 易 的 事情 。 好 在 Flux 的 dispatcher 定义 了 严格 的 规 
则 来 限定 我 们 对 数据 的 修改 操作 。 同 时 ，store 中 不 能 暴露 setter 的 设 定 也 强化 了 数据 修改 的 纯洁 
性 ， 保 证 了 store 的 数据 确定 应 用 唯一 的 状态 。 


再 使 用 React 作为 Flux 的 view， 虽 然 每 次 view 的 泻 染 都 是 重 泻 染 ， 但 并 不 会 影响 页 面 的 性 
能 ， 因 为 重演 染 的 是 Virtual DOM， 并 由 PureRender 保障 从 重演 染 到 局 部 泻 染 的 转换 。 意 味 着 完 
全 不 用 关心 演 染 上 的 性 能 问题 ， 增 、 删 、 改 的 泻 染 都 和 初始 化 泻 染 一 样 快 。 

Flux 看 起 来 非常 完美 ， 那 么 它 真 得 比 MVC 好 吗 ? 事实 上 ， 在 前 端 领域 ，Flux 还 是 一 个 处 于 
非常 早期 的 架构 方式 。 

对 于 一 些 逻 辑 复杂 的 前 端 应 用 ( 比如 Firefox 中 的 调试 器 )，Flux 已 经 证 明了 自己 确实 能 够 极 
大 地 降低 复杂 度 。 但 是 对 于 许多 原本 使 用 MVC 方式 架构 都 绰绰有余 的 项 目 来 说 ，EFlux 看 起 来 像 
是 杀 鸡 用 牛刀 。 

我 们 现在 无 法 断言 Flux 一 定 在 任何 场景 下 都 优 于 MVC， 甚 至 在 某 些 简单 的 应 用 中 ， 你 会 发 
现 使 用 Backbone 等 传统 MVC 框架 解决 起 来 会 更 加 顺手 。 

甚至 在 开源 社区 中 ， 有 人 认为 前 端的 Flux 架构 与 早期 Win32 中 的 wndProc() 窗口 过 程 函 数 
的 设计 颇 为 类 似 "。 

但 是 这 些 都 不 能 掩盖 Flux 作为 一 种 全 新 的 前 端 架构 方式 给 我 们 带 来 的 思想 上 的 冲击 与 转 
变 。Flux 强调 单 向 数据 流 ,， 强 调 谨慎 可 追溯 的 数据 变动 , 这 些 设计 和 约束 都 使 得 前 端 应 用 在 越 来 
越 复杂 的 今天 不 会 失去 清晰 的 逻辑 和 架构 。 
























































































































































4.3 Flux 基本 概念 


了 解 了 为 什么 我 们 会 选择 Flux 模式 之 后 ， 下 面 来 讲述 它 的 基本 概念 和 组 成 。 

一 个 Flux 应 用 由 3 大 部 分 组 成 一 dispatcher、store 和 view， 其 中 dispatcher 负责 分 发 事件 ; 
store 负责 保存 数据 ， 同 时 响应 事件 并 更 新 数据 ; view 负责 订阅 store 中 的 数据 ， 并 使 用 这 些 数 据 
泻 染 相应 的 页 面 。 

尽管 它 看 起 来 和 MVC 架构 有 些 像 ， 但 其 中 并 没有 一 个 职责 明确 的 controller。 事 实 上 ，Flux 
中 存在 一 个 controller-view 的 角色 , 但 它 的 职责 是 将 view 与 store 进行 绑 定 ,并 没有 传统 MVC 中 
controller 需要 承担 的 复杂 逻辑 。 


图 4-5 是 Flux 应 用 的 简化 执行 流程 ， 下 面 我 们 将 依次 介绍 各 个 节点 的 作用 。 















































GD The More Things Change， 详 见 https://bitquabit.com/post/the-more-things-change/。 
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Controller-View 





Action Creator 


触发 


action 


1. dispatcher 与 action 

如 果 你 熟悉 Backbone 的 话 ， 肯 定 对 Backbone 的 事件 机 制 印 象 深刻 。 与 Backbone 的 发 布 / 订 
阅 模式 不 同 ，Flux 中 的 事件 会 由 若干 个 中 央 处 理 器 来 进行 分 发 ， 这 就 是 dispatcher。 

dispatcher 是 Flux 中 最 核心 的 概念 ， 也 是 fLux 这 个 npm 包 中 的 核心 方法 。 

事实 上 ，dispatcher 的 实现 非常 简单 ， 我 们 只 需要 关心 .register(callback) 和 .dispatch 
(action) 这 两 个 API 即 可 。 

register 方法 用 来 注册 一 个 监听 器 ， 而 dispatch 方法 用 来 分 发 一 个 action。 

action 是 一 个 普通 的 JavaScript 对 象 ， 一 般 包含 type 、payload 等 字段 ， 用 于 描述 一 个 事件 以 
及 需要 改变 的 相关 数据 。 比 如 点 击 了 页 面 上 的 某 个 按钮 ， 可 能 会 触发 如 下 action: 


{ 
"type": "CLICK_BUTTON" 


} 

这 是 action 最 简单 的 一 种 形式 。 在 实际 应 用 中 ， 一 个 action 还 可 能 包含 更 多 的 信息 ， 比 如 某 
个 操作 对 应 的 用 户 ID、 当 前 操作 是 否 出 现 错 误 的 标志 位 等 。 

在 开源 社区 中 ， 有 一 套 关于 Flux 中 action 对 象 该 如 何 定义 的 规范 ， 称 为 FSA (Flux Standard 
Action )“。 该 规范 定义 了 一 个 Flux action 必须 拥有 一 个 type 字段 ， 可 以 拥有 error 、paytLoad 或 
meta 字段 。 除 此 之 外 ， 不 能 有 其 他 额外 的 字段 。 

2. store 

在 Flux 中 ，store 负责 保存 数据 ,并 定义 修改 数据 的 逻辑 ,同时 调用 dispatcher 的 register 方 
法 将 自己 注册 为 一 个 监听 器 。 这 样 每 当 我 们 使 用 dispatcher 的 dispatch 方法 分 发 一 个 action 时 ， 


















分 发 action 


图 4-5 Flux 流程 图 




























































































GD Flux Standard Action， 详 见 https://github.com/acdlite/flux-standard-action。 
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store 注册 的 监听 器 就 会 被 调用 ， 同 时 得 到 这 个 action 作为 参数 。 

store 一 般 会 根据 action 的 type 字段 来 确定 是 否 响应 这 个 action。 若 需要 响应 , 则 会 根据 action 
中 的 信息 修改 store 中 的 数据 ， 并 触发 一 个 更 新 事件 。 

需要 特别 说 明 的 是 , 在 Flux 中 ，store 对 外 只 暴露 getter ( 读 取 需 ) 而 不 暴露 setter ( 设置 右 )， 
这 意味 着 在 store 之 外 你 只 能 读 取 store 中 的 数据 而 不 能 进行 任何 修改 。 

3. controller-view 

虽然 说 Flux 的 3 大 部 分 是 dispatcher 、store 和 view, 但 是 在 这 三 者 之 间 存 在 着 一 个 简单 却 不 
可 或 缺 的 角色 一 一 controller-view。 顾 名 思 义 ， 它 既 像 controller， 又 像 view， 那 么 controller-view 
究竟 在 Flux 中 发 挥 什么 样 的 作用 呢 ? 

一 般 来 说 ，controller-view 是 整个 应 用 最 顶层 的 view， 这 里 不 会 涉及 具体 的 业务 逻辑 ， 主 要 
进行 store 与 React 组 件 ( 即 view 层 ) 之 间 的 绑 定 ， 定 义 数据 更 新 及 传递 的 方式 。 

controller-view 会 调用 store 暴露 的 getter 获取 存储 其 中 的 数据 并 设置 为 自己 的 state， 在 
render 时 以 props 的 形式 传 给 自己 的 子 组 件 (this.props.children )。 

介绍 store 时 我 们 说 过 ， 当 store 响应 某 个 action 并 更 新 数据 后 ， 会 触发 一 个 更 新 事件 ,这 个 更 
新 事件 就 是 在 controller-view 中 进行 监听 的 。 当 store 更 新 时 ，controller-view 会 重新 获取 store 中 
的 数据 ， 然 后 调用 setstate 方法 触发 界面 重 绘 。 这 样 所 有 的 子 组 件 就 能 获得 更 新 后 store 中 的 数 
据 了 。 

4. view 

在 绝 大 多 数 的 例子 里 ，view 的 角色 都 由 React 组 件 来 扮演 ， 但 是 Flux 并 没有 限定 view 具体 
的 实现 方式 。 因 此 ， 其 他 的 视图 实现 依然 可 以 发 挥 Flux 的 强大 能 力 , 例如 结合 Angular 、Vue 等 。 

在 Flux 中 ，view 除了 显示 界面 ， 还 有 一 条 特殊 的 约定 : 如 果 界 面 操作 需要 修改 数据 ， 则 必 
须 使 用 dispatcher 分 发 一 个 action。 事 实 上 , 除了 这 么 做 , 没有 其 他 方法 可 以 在 Flux 中 修改 数据 。 

这 条 限制 对 刚 接触 Flux 的 开发 者 来 说 难以 理解 。 因 为 在 React 中 需要 修改 数据 的 时 候 ， 直接 
调用 this.setstate 方法 即 可 。 如 果 需 要 分 发 action， 那 么 action 是 什么 样 的 ， 分 发 到 哪里 ， 由 
谁 来 处 理 ，View 层 如 何 更 新 ?这 些 疑问 我 们 会 在 4.4 节 中 一 一 讲解 。 目 前 只 需要 知道 Flux 中 的 
view 层 不 能 直接 修改 数据 就 可 以 了 。 

5. actionCreator 

与 controller-view 一 样 ，actionCreator 并 不 是 Flux 的 核心 概念 ， 但 在 许多 关于 Flux 的 例子 和 
文章 中 都 会 看 到 这 个 名 词 ， 因 此 有 必要 解释 一 下 。actionCreator， 顾 名 思 义 ， 就 是 用 来 创造 action 
的 。 为 什么 需要 actionCreator 呢 ? 因为 在 很 多 时 候 我 们 在 分 发 action 的 时 候 代 码 是 宛 余 的 。 

考虑 一 个 点 赞 的 操作 ， 如 果 用 户 给 某 条 微 博 点 了 赞 ， 可 能 会 分 发 一 个 这 样 的 action: 
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{ 
type: 'CLICK_UPVOTE', 


payload: { 
weiboId: 123， 
和 
} 


而 包含 完整 分 发 逻辑 的 代码 更 加 复杂 : 


import appDispatcher from '../dispatcher/appDispatcher'; 


// 响应 点 赞 的 onClick 方法 


handleClickUpdateVote(weiboId) { 
appDispatcher .dispatch({ 
type: 'CLICK_UPVOTE', 
payload: { 
weiboId: weiboId ， 
}， 
]); 
} 





事实 上 ， 在 分 发 action 的 6 行 代码 中 ， 只 有 1 行 是 变化 的 ， 其 余 5 行 都 固定 不 变 ， 这 时 我 们 4 
可 以 创建 一 个 actionCreator 来 帮 减 少 元 余 的 代码 ， 同 时 方便 重用 逻辑 : 


// actions/AppAction.js 
import appDispatcher from 


../dispatcher/appDispatcher'; 


function upvote(weiboId) { 
appDispatcher .dispatch({ 
type: 'CLICK_UPVOTE', 
payload: { 
weiboId: weiboId ， 
}, 
}); 
} 


// components/Weibo.js 
import { upvote } from '../actions/AppAction'; 


handleClickUpdateVote(weiboId) { 
Upvote(weiboId); 
} 








可 以 看 到 ,在 view 中 ,分 发 action 变 得 异常 简洁 。 同 时 当 我 们 需要 修改 upvote 的 逻辑 时 ， 
只 需要 在 actionCreator 中 进行 修改 即 可 ， 所 有 调用 upvote 的 view 都 无 需 变动 。 
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4.4 Flux 应 用 实例 


在 4.1 节 中 ， 我们 实现 了 一 个 评论 框 组 件 ， 这 个 组 件 包 含 了 已 有 评论 的 列表 和 评论 表单 两 个 
组 件 。 接 下 来 ， 我 们 会 对 它 进行 简单 的 修改 ， 让 它 成 为 我 们 实现 的 第 一 个 Flux App。 





4.4.1 初始 化 目录 结构 


Flux App 是 一 个 完整 的 前 端 应 用 ,代码 按照 不 同 的 功能 有 着 严格 的 划分 ,因此 它 不 像 React 组 
件 那样 逻辑 、 样 式 和 数据 都 放 在 同一 个 地 方 。 现 在 我 们 来 介绍 Flux 应 用 最 基本 的 结构 : 
一 一 CSS 
| LL app.css 
is 
上 一 actions/ 
| 一 components/ 
上 一 constants/ 
-一 dispatcher/ 


上 一 stores/ 
上 一 appjs 
可 以 看 到 ， 在 目录 结构 的 最 顶层 ， 我 们 按照 传统 的 方式 区 分 了 JavaScript 文件 和 CSS 文件 。 
不 过 在 后 面 的 例子 中 ， 你 会 发 现 对 于 React 组 件 来 说 ， 把 JavaScript 和 CSS 放 在 一 起 是 更 高 效 和 
方便 的 方式 。 在 本 例 中 ， 为 了 理解 方便 ， 依 然 使 用 传统 的 划分 方式 。 
在 JavaScript 中 ， 基 本 上 就 是 按照 我 们 在 4.3 节 中 讲 到 的 各 种 概念 划分 了 目录 结构 ， 不 过 有 
些许 不 同 。 


首先 ， 没 有 名 为 view 的 文件 来， 取而代之 的 是 components 文件 夹 。 所 有 视图 相关 的 组 件 都 
放 在 components 中 ， 包 括 之 前 提 到 的 与 store 进行 绑 定 的 controller-view。 


其 次 ， 多 了 一 个 名 为 constants 的 文件 夹 。 为 什么 需要 constants 呢 ? 不 知 你 是 否 注意 到 ， 在 
Flux 中 是 通过 type 字段 来 区 分 不 同 的 action 的 ， 那 么 这 些 type 字段 势必 会 成 为 字符 串 常 量 。 既 
然 是 常量 , 在 所 有 actionCreator 出 现时 , 都 应 该 保持 一 致 。 因 此 , 抽出 常量 统一 放 在 constants 文 
件 夹 中 便 是 一 个 不 错 的 选择 。 


而 在 app.js 中 ， 我 们 会 把 components 中 的 controller-view 使 用 ReactDOM 的 render 方法 演 
染 到 真实 的 DOM 中 。 


































































































4.4.2 设计 store 


在 之 前 的 例子 中 ， 所 有 的 数据 都 是 保存 在 组 件 的 state 中 。 而 在 Flux 模式 下 ， 数 据 需要 被 迁 
移 到 store 里 : 


// store/CommentStore.js 
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let comment = []; 


可 以 看 到 ，store 里 保存 的 数据 被 直接 定义 在 模块 中 ,没有 调用 任何 方法 ,它们 是 原生 的 


县 


JavaScript 变量 。 


有 了 初始 化 的 变量 还 不 够 ， 我们 还 需要 定义 数据 的 修改 逻辑 。 在 这 个 例子 中 ，store 中 修改 
数据 的 逻辑 十 分 简单 ， 就 是 从 服务 器 取出 最 新 的 评论 列表 即 可 : 
// store/CommentStore.js 


function loadComment(newComment) { 
comment = newComment; 


} 

与 数据 一 样 ， 修 改 数据 的 方法 也 是 平淡 无 奇 的 方法 ,接受 新 的 评论 列表 作为 参数 ， 并 将 它 赋 
给 store 中 保存 的 comment。 

如 果 熟 悉 Node 中 模块 的 概念 , 会 发 现 我 们 的 store 中 没有 导出 任何 内 容 。 这 意味 着 其 他 模块 
在 引入 store 时 ， 将 会 得 到 undefined。 因 此 ， 我 们 的 store 需要 一 个 统一 的 出 口 : 























// store/CommentStore.js 
import { EventEmitter } from 'events'; 
import assign from 'object-assign'; 


const CommentStore = assign({}, EventEmitter.prototype, { 
getComment() { 
return comment; 


}, 


emitChange() { 
this.emit('change'); 


}, 


addChangeListener(callback) { 
this.on('change', callback); 
}, 


removeChangeListener(caLLback) { 
this.removelListener(callback); 
} 
]); 


export default CommentStore; 


在 这 部 分 store 的 设计 中 ， 我 们 引入 了 Node 自 带 的 events 模块 中 的 EventEmitter， 并 使 用 
assign 方法 将 EventEmitter 的 功能 混入 CommentStore 中 ， 这 样 store 就 拥有 了 事件 触发 和 监听 的 
功能 。 当 然 ， 从 更 优雅 的 角度 来 讲 ， 也 可 以 用 类 来 实现 。 


而 在 具体 的 store 中 ，getComment 方法 会 返回 store 中 保存 的 所 有 评论 数据 ， 也 就 是 前 面 提 到 
的 store 中 对 外 暴露 的 getter。 此 外 , 还 有 emitChange、addChangeListener 和 removeChangeListener 
这 3 个 方法 ,我们 会 在 controller-view 中 看 到 它们 的 具体 作用 。 
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最 后 ， 我 们 将 store 暴露 出 去 ， 这样 使 用 store 的 地 方 就 可 以 调用 CommentStore.getComment() 
方法 获取 store 中 保存 的 评论 数据 了 。 

似乎 还 少 点 什么 ”是 的 ，store 中 的 数据 如 何 修改 呢 ? 没 错 ， 我 们 还 需要 调用 dispatcher 的 
register 方法 注册 一 个 监听 器 ， 用 于 响应 具体 的 action : 








../dispatcher/AppDispatcher'; 
'../constants/CommentConstants'; 


import AppDispatcher from 
import CommentConstants from 


const CommentStore = { 
// 具体 实现 见 前 面 
}; 


AppDispatcher .register((action) => { 
switch (action.type) { 
case CommentConstants.LOAD COMMENT_SUCCESS: { 
comment = action.payload.comment.commentList; 
CommentStore.emitChange(); 
} 
} 
]); 


export default CommentStore; 


在 我 们 注册 的 回调 中 ， 针 对 LOAD_COMMENT_SUCCESS 这 个 类 型 的 事件 修改 了 store 中 的 数据 ， 
这 也 是 例子 中 唯一 一 处 数据 的 修改 逻辑 。 




















4.4.3 设计 actionCreator 


在 Flux 中 ,一 个 action 的 触发 意味 着 需要 修改 数据 ， 那 么 在 我 们 的 评论 框 中 ， 有 哪些 数据 
要 修改 呢 ? 一 个 是 提交 新 的 评论 , 一 个 是 从 服务 端 获 取 评 论 列 表 。 下 面 让 我 们 分 别 为 这 两 个 方法 


设计 actionCreator: 











// actions/CommentActions.js 
import AppDispatcher from 
import CommentConstants from 


../dispatcher/AppDispatcher'; 
'../constants/CommentConstants'; 


const CommentActions = { 
LoadComment() { 
AppDispatcher .dispatch({ 
type: CommentConstants.LOAD_COMMENT, 


3 


fetch('/api/response.json') 
.then((res) => { 
return res.json(); 
}) 
.then((value) => { 
AppDispatcher .dispatch({ 
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type: CommentConstants.LOAD_ COMMENT_SUCCESS, 

payload: { 

comment: value, 

}, 

}); 
}) 
.Catch((err) => { 

AppDispatcher .dispatch({ 
type: CommentConstants .LOAD_COMMENT_ERROR, 
error: err, 
}); 
]); 
}， 


addComment(text) { 
AppDispatcher .dispatch({ 
type: CommentConstants.ADD_COMMENT, 
}); 


fetch('/api/submit.json', { 
method: 'POST', 
body: JSON.stringify({value: encodeURI(text)}), 
headers: { 
'Accept': 'application/json', 
'Content-Type': 'application/json', 
]， 
}) 
.then((res) => { 
return res.json(); 
}) 
.then((vaLue) => { 
if (value.ok) { 
AppDispatcher .dispatch({ 
type: CommentConstants.ADD_COMMENT_SUCCESS, 
payload: { 
comment: value, 
}, 
]); 
this. loadComment(); 
} 
}) 
.Catch((err) => { 
AppDispatcher .dispatch({ 
type: CommentConstants.ADD_COMMENT_ERROR ， 
error: err， 


})); 





}; 
export default CommentActions; 


actionCreator 中 的 代码 看 起 来 似乎 比 store 中 复杂 了 不 少 。 仔 细 观 察 会 发 现 ， 我 们 定义 的 两 
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个 actionCreator 有 着 同样 的 套路 ， 都 使 用 了 fetch 来 发 送 Ajax 请 求 ， 在 发 送 请 求 前 分 发 了 一 个 
action， 在 请 求 成 功 响应 后 分 发 了 一 个 action， 在 请 求 出 现 异常 时 同样 分 发 了 action。 


你 可 能 觉得 这 种 设计 有 些 宛 余 , 但 是 它 却 能 给 用 户 界面 带 来 更 高 的 可 控制 性 。 在 应 用 开发 中 ， 
经 常 存在 一 些 耗 时 比较 久 的 异步 操作 。 为 了 更 好 的 用 户 体验 , 我 们 需要 知道 什么 时 候 应 该 展示 加 
载 中 的 图 标 ， 什 么 时 候 又 应 该 把 它 隐藏 以 免 影 响 用 户 的 正常 操作 。 这 些 状态 的 变化 ， 都 在 
actionCreator 中 得 以 体现 。 这 里 为 了 保持 例子 简单 ， 我 们 并 没有 在 store 和 view 中 处理 这 些 状 
态 , 但 是 你 应 该 了 解 并 尽 可 能 地 显示 这 些 状态 。 


4.4.4 构建 controller-view 
设计 好 了 store 和 action， 是 时 候 把 它们 拼装 到 一 起 了 : 


// components/CommentBox.js 

import React, { Component } from 'react'; 

import CommentStore from '../stores/CommentStore'; 
import CommentList from './CommentList'; 

import CommentForm from './CommentForm'; 







































































class CommentBox extends Component { 
constructor(props) { 
super (props); 


this._onChange = this._onChange.bind(this); 


this.state = { 
comment: CommentStore.getComment(), 
}; 
} 


_onChange() { 
this.setState({ 
comment: CommentStore.getComment(), 
}); 
} 


componentDidMount() { 
CommentStore.addChangeListener(this._onChange); 


} 


componentWillUnmount() { 
CommentStore.removeChangeListener(this._onChange); 


} 


render() { 
return ( 
<div> 
<CommentList comment={this.state.comment} /> 
<CommentForm /> 
</div> 


); 
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} 
} 


export default CommentBox; 


在 我 们 的 controller-view 中 ， 有 3 处 值得 注意 的 地 方 。 


口 定义 了 组 件 初 始 化 的 状态 使 用 store 暴露 给 我 们 的 getComment 方法 从 CommentStore 
中 获取 评论 列表 。 

口 在 componentDidMount 和 componentWtLLUnmount 中 分 别 对 store 的 change 
解 乡 ， 这 也 解释 了 为 什么 我 们 的 store 需要 EventEmttter。 

口 定义 了 一 个 store 变化 的 回调 函数 ， 在 这 个 回调 也 数 里 ， 重 新 调用 store 的 getComment 方 
法 获取 最 新 的 评论 并 调用 this.setState 方法 更 新 controller-view 自己 的 state。 当 然 ， 这 
些 state 最 终 会 作为 components 的 props 传递 给 各 个 子 组 件 。 








有 件 作 了 绑 定 及 


hl 














4.4.5 重 构 view 


在 4.1 节 的 例子 中 ,我 们 已 经 写 好 了 CommentList 和 CommentBox 两 个 组 件 ， 但 是 在 Flux 架 
构 中 ， 我 们 需要 做 一 些 简 单 的 调整 : 





// components/CommentList.js 
import React, { Component } from 'react'; 
import CommentActions from '../actions/CommentActions'; 


class CommentList extends Component { 
componentDidMount() { 
CommentActions.loadComment(); 


} 


render() { 
const list = this.props.comment; 


return ( 
<UL className="comment-box"> 
{list.map((entry, i) => ( 
<li key={ “reponse-${i} } className="comment-item"> 
<p className="comment-item-name">{entry.name}</p> 
<p className="comment-item-content">{entry.content}</p> 
</li> 
))} 
</ul> 
); 
} 
} 


export default CommentList; 


对 于 CommentList 来 说 ， 去 除了 原 有 的 从 promise 中 获取 数据 的 逻辑 。 因 为 所 有 的 数据 都 在 
controller-view 中 传递 了 进来 ， 所 以 CommentList 便 可 以 作为 一 个 与 具体 逻辑 无 关 的 纯 展 示 组 件 。 
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但 是 store 中 默认 的 评论 数据 是 一 个 空 数组 ， 怎 样 才能 从 服务 器 获取 到 已 有 的 评论 呢 ? 很 简 


单 ， 我 们 之 前 在 CommentAction 中 定义 了 从 服务 器 获取 数据 的 LoadComment 方法 ， 


CommentList 组 件 中 调用 该 方法 即 可 。 
下 面 让 我 们 看 看 CommentForm: 


// components/CommentForm.js 
import React, { Component } from 'react'; 
import CommentActions from '../actions/CommentActions'; 








class CommentForm extends Component { 
constructor(props) { 
super (props); 


this.handleChange = this.handleChange.bind(this); 
this.handleAddComment = this.handleAddComment.bind(this); 


this.state = { 
value: ''， 


3 
} 


handleChange(event) { 
this.setState({ vaLue: event.target.valuyue }); 


} 


handleAddComment() { 
CommentActions.addComment(this.state.value); 


} 


render() { 
return ( 
<div> 
<textarea 
value={this. state.value} 
onChange={this.handleChange} 
/> 
<button 
className="comment-confirm-btn" 
onClick={this.handleAddComment} 
> 评论 </button> 
</div> 
); 
} 
} 


export default CommentForm; 


同 理 ,我 们 在 CommentForm 中 引入 了 在 CommentAction 中 定义 的 addComment 方法 来 处 理 评 


论 提 交 的 问题 。 

















直接 在 








I 


你 可 能 会 好 奇 ，Flux 中 不 是 强调 改变 数据 一 定 要 分 发 action 吗 ? 为 什么 修改 textarea 中 的 
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值 依然 使 用 了 setstate。 实际 上 , 这 是 一 个 设计 上 的 权衡 。 如 果 明 确 地 知道 某 个 局 部 状态 不 会 影 
啊 整 个 应 用 中 的 其 他 部 分 ， 也 不 需要 初始 化 的 时 候 进 行 赋值 ,那么 出 于 简化 实现 的 考虑 ,可 以 把 
这 个 状态 保存 在 组 件 中 。 


4.4.6 添加 单元 测试 


在 2.8 节 中 ， 我 们 讲 到 了 使 用 Jest 或 Enzyme 对 React 组 件 进行 单元 测试 。 而 在 Flux 应 用 中 ， 
除了 React 组 件 外 ， 更 核心 的 功能 当 属 store。 那 么 我 们 如 何 为 Flux 中 的 store 添加 单元 测试 呢 ? 


我 们 知道 ，Flux 中 的 store 为 了 限制 对 数据 的 随意 更 改 ， 并 没有 对 外 暴露 任何 直接 修改 数据 
的 接口 。 要 想 让 store 中 的 数据 发 生 改 变 ，store 必须 使 用 dispatcher 注册 一 个 监听 器 ， 这 样 每 当 
dispatcher 分 发 一 个 action 的 时 候 ，store 才 会 得 到 通知 并 相应 地 修改 数据 。 

为 了 在 测试 中 模拟 这 种 机 制 ， 我 们 需要 用 到 一 点 技巧 。 

在 2.8 节 中 我 们 说 到 ，Jest 会 自动 模拟 所 有 的 依赖 ， 这 意味 着 在 Jest 测 试用 例 中 ，require 的 
所 有 文件 默认 都 是 Jest 帮 有 我 们 伪造 的 。 实 际 上 ,每 一 个 Jest 伪造 的 对 象 除了 原本 拥有 的 属性 和 方 
法 外 ， 还 会 给 每 一 个 被 伪造 的 方法 添加 一 个 名 为 mock 的 属性 ， 以 方便 我 们 在 测试 用 例 中 观察 测 
试 的 执行 情况 及 执行 相关 的 断言 。 在 mock 属性 中 ， 最 重要 的 则 是 catls 字段 ， 这 个 字段 用 来 表 
示 当 前 被 模拟 的 方法 被 调用 时 的 参数 。 

比如 ， 应 用 有 一 个 模块 名 为 myDpeps， 对 外 暴露 了 foo 方法 和 bar 属 1 

Const myDeps = { 


foo() { 


console.log('a'); 




































































中 


bar: 1， 


module.exports = myDeps; 


因此 , 在 测试 用 例 中 ， 只 要 引用 myDeps， 我 们 就 可 以 使 用 Jest 为 我 们 伪造 出 来 的 新 对 象 。 而 
deps .foo.mock 则 是 Jest 额外 为 foo 方法 添加 的 属性 ， 通 过 这 个 属性 我 们 可 以 追踪 foo 方法 被 调 
用 的 情况 。 举 个 具体 的 例子 ，deps .foo.mock.calls[0] 可 以 获取 到 foo 方法 第 一 次 被 调用 时 传人 
的 所 有 参数 ， 这 是 一 个 数组 。 因 此 ， 显而易见 的 是 ，deps .foo.mock.calls[9][9] 是 该 方法 第 一 次 
被 调用 时 传人 的 第 一 个 参数 。 


了 解 了 Jest 的 这 一 特点 后 , 回 到 Flux store 的 测试 用 例 中 。 首先 引入 应 用 的 dispatcher，Jest 会 
自动 对 dispatcher 的 所 有 方法 和 属性 进行 模拟 , 然后 拿 到 调用 dispatcher.register 方法 时 传人 的 
一 个 参数 ， 即 store 的 监听 器 : 















































import mockDispatcher from '../dispatcher/AppDispatcher'; 
const listener = mockDispatcher.register.mock.calls[0][0]; 
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回想 一 下 ， 在 store 中 我 们 就 是 通过 注册 这 个 监听 需 来 获取 发 生 的 变更 一 某 一 action 被 分 
发 了 。 因 此 , 我 们 只 需要 给 listener 传人 特定 的 action ， 再 断言 store 中 的 数据 变更 符合 预期 即 可 。 


假设 我 们 的 应 用 是 一 个 计数 器 ，store 中 保存 的 数据 每 当 “ 加 1” 的 action 发 生 时 则 自动 加 1， 
并 能 通过 store.getCount() 方法 获取 。 一 个 完整 的 例子 如 下 : 


jest.dontMock('../stores/MyStore'); 








import AppDispatcher from '../dispatcher/AppDispatcher'; 
import MyStore from '../store/MyStore'; 


describe('MyStore', () => { 
it('should add 1', () => { 
const listener = AppDispatcher.register.mock.calls[90][90]; 


// 模拟 类 型 为 INCREMENT 的 action 被 触发 ， 断 言 store 能 够 正常 响应 这 个 action 
lisenter({ 

type: 'INCREMENT' 
}); 


expect(MyStore.getCount()).to.equal(1); 
}); 
]); 
到 此 ， 第 一 个 Flux App 已 经 基本 完成 。 可 以 看 到 ，Flux 强调 的 单 向 数据 流 在 很 大 程度 上 让 
应 用 的 逻辑 变 得 更 加 清晰 ， 而 泻 染 的 视图 组 件 也 让 关注 分 离 ( Separation of Concerns ) 的 设计 思 
想得到 了 很 好 的 贯彻 执行 。 











4.5 解读 Flux 


当 我 们 明白 了 Flux 的 设计 思想 和 工作 原理 后 ， 可 能 会 感叹 原来 Flux 如 此 简单 。 

正如 在 介绍 Flux 基本 概念 时 说 的 那样 ，Facebook 提供 的 flux 依赖 包 里 ， 核 心 只 有 一 个 
dispatcher。 当 然 ， 在 后 续 版 本 中 ， 又 增加 了 一 些 方便 函数 式 编 程 的 utils 方法 与 语法 糖 。 可 以 说 ， 
Flux 更 像 是 一 种 设计 模式 ， 而 不 是 一 个 具体 的 框架 或 者 库 。 


















































4.5.1 ”Flux 核心 思想 

Flux 架构 是 优雅 、 简 洁 的 ， 它 合理 利用 了 一 些 优秀 的 架构 思维 。 

Flux 的 中 心 化 控制 让 人 称道 。 中 心 化 控制 让 所 有 的 请 求 与 改变 都 只 能 通过 action 发 出 ， 统 一 
由 dispatcher 来 分 配 。 好 处 是 View 可 以 保持 高 度 简 洁 ， 它 不 需要 关心 太 多 的 逻辑 ， 只 需要 关心 
传人 的 数据 ; 中心 化 还 控制 了 所 有 数据 ， 发 生 问题 时 可 以 方便 查询 。 比 起 MVC 架构 下 数据 或 逻 
辑 的 改动 可 能 来 自 多 个 完全 不 同 的 源头 ，Flux 架构 追查 问题 的 复杂 度 和 困难 度 显 然 要 小 得 多 。 


此 外 ，Flux 把 action 做 了 统一 归纳 ， 提 高 了 系统 抽象 程度 。 不 论 action 是 由 用 户 触发 的 ， 从 
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服务 端 发 起 的 ， 还 是 应 用 本 身 的 行为 ， 对 于 我 们 而 言 ， 它 都 只 是 一 个 动作 而 已 。 与 MVC 架构 下 
不 同 的 触发 方式 管理 混乱 相 比 ，Flux 要 优雅 许多 。 





4.5.2 Flux 的 不 足 

尽管 Flux 是 刚刚 推出 不 久 的 设计 模式 , 开发 者 们 已 经 开始 发 现 Flux 存在 或 多 或 少 的 设计 缺陷 。 

其 中 最 邻 人 诉 病 的 就 是 Flux 的 宛 余 代 码 太 多 。 虽 然 Flux 源码 中 几乎 只 有 dispatcher 的 现实 ， 
但 是 在 每 个 应 用 中 都 需要 手动 创建 一 个 dispatcher 的 示例 ， 这 还 是 让 很 多 开发 者 觉得 烦恼 。 

说 到 底 ，Flux 给 开发 者 提供 的 还 是 它 的 思想 。 由 于 Flux 在 很 大 程度 上 是 一 种 很 松散 的 设计 
约定 ， 不 同 的 开发 者 对 Flux 都 会 有 自己 的 理解 。 因 此 ， 在 这 几 年 开源 社区 的 讨论 中 ， 到 处 都 充 
斥 着 各 种 各 样 对 于 Flux 思想 的 不 同 实 现 ， 它 们 都 在 尝试 解决 Flux 中 没有 提 到 或 未 解决 的 问题 。 

































































4.6 ”小结 

我 们 讲述 了 Flux 相 比 于 传统 的 MVC 的 不 同 ， 也 通过 一 个 简单 的 例子 阐述 了 Flux 的 工作 方 
法 ， 但 是 要 真正 领略 Flux 的 优美 与 强大 ， 仍 需要 从 一 个 复杂 的 应 用 入 手 亲自 去 尝试 。 

近 几 年 来 ，Flux 的 诸多 变种 如 雨后春笋 般 出 现 ， 其 中 Redux 和 Refluxjs 可 能 是 其 中 最 有 名 的 
两 个 ， 我 们 可 以 通过 比较 这 些 不 同 的 Flux 思想 实现 来 了 解 Flux 生态 圈 "。 

在 下 一 章 中， 我 们 将 详细 介绍 Flux 思想 的 最 著名 实现 一 Redux。 事 实 上 ，Redux 的 知名 度 
已 经 超越 了 Flux， 成 为 开源 社区 中 目前 最 火 的 前 端 应 用 架构 。 









































GD Flux comparison, 详 见 https://github.com/voronianski/flux-comparison。 





深入 Redux 应 用 架构 








从 Flux 身上 我 们 领略 到 数据 在 store 、action creator 、dispatcher 及 React 组 件 之 间 单 向 流动 的 
美妙 特性 ， 但 在 它 受到 越 来 越 多 关注 的 同时 ， 我 们 也 发 现 了 Flux 的 一 些 问题 与 不 足 。 因 此 , 优 
化 和 扩展 Flux 架构 的 方案 不 断 涌 现 ， 其 中 不 乏 许 多 高 质量 的 作品 , 如 reflux、fluxxor 等 。 但 是 很 
快 ， 一 个 后 起 之 秀 脱颖而出 ， 短 短 数 月 就 在 GitHub 上 收获 近 万 star， 它 就 是 Redux。 


为 什么 Redux 在 短 时 间 内 就 受到 了 如 此 高 的 追捧 ? Redux 和 Flux 相 比 有 什么 异同 ?如 何 从 
零 开始 搭建 一 个 Redux 应 用 ? 这 些 问 题 将 在 本 章 中 一 一 为 你 揭晓 。 











5.1 Redux 简介 


现在 我 们 就 从 Redux 是 什么 、Redux 的 三 大 原则 和 Redux 的 核心 API 开始 介绍 Redux ， 并 说 
明 Redux 如 何 与 React 结合 使 用 ， 以 及 它 在 Flux 基础 上 的 改变 。 




















5.1.1 Redux 是 什么 


我 们 都 知道 Flux 本 身 既 不 是 库 ， 也 不 是 框架 ， 而 是 一 种 应 用 的 架构 思想 。 而 Redux 呢 ， 它 
的 核心 代码 可 以 理解 成 一 个 库 ， 但 同时 也 强调 与 Flux 类 似 的 架构 思想 。 

从 设计 上 看 ，Redux 参考 了 Flux 的 设计 ， 但 是 对 Flux 许多 元 余 的 部 分 (如 dispatcher ) 做 了 
简化 ， 同 时 将 Elm 语言 中 函数 式 编程 的 思想 融合 其 中 。 

非常 有 意思 的 是 ，Redux 是 从 一 个 实验 开始 的 ,作者 Dan Abramov 并 没有 想到 Redux 会 变 得 
如 此 重要 又 被 广泛 使 用 ， 他 只 是 为 了 通过 Flux 思想 解决 他 的 热 重 载 及 时 间 旅 行 的 问题 而 已 。 

Redux 本 身 非 常 简单 ， 它 的 设计 思想 与 React 有 异曲同工 之 妙 ， 均 是 希望 用 最 少 的 API 实现 
最 核心 的 功能 。 
图 5-1 是 Redux 的 核心 运作 流程 ， 看 起 来 比 Flux 要 简单 不 少 。 因 为 Redux 本 身 只 把 自己 定 
位 成 一 个 “可 预测 的 状态 容器 ”， 所 以 图 5-1 只 能 算是 这 个 容器 的 运行 过 程 。 而 一 个 完整 的 Redux 
应 用 的 运作 流程 ， 远 比 图 5-1 复杂 得 多 。 
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图 5-1 Redux 的 核心 运作 流程 


“Redux” 本 身 指 redux 这 个 npm 包 ， 它 提供 若干 API 让 我 们 使 用 reducer 创建 store， 并 能 够 
更 新 store 中 的 数据 或 获取 store 中 最 新 的 状态 。 而 “Redux 应 用 ” 则 是 指使 用 了 redux 这 个 npm 包 





并 结合 了 视图 层 实现 ( 如 React ) 及 其 他 前 端 应 用 必 备 组 件 


的 类 Flux 思想 的 前 端 应 用 。 








5.1.2 Redux 三 大 原则 





( 路 由 库 、Ajax 请 求 库 ) 组 成 的 完整 


想 要 理解 Redux， 必 须要 知道 Redux 设计 和 使 用 的 三 大 原则 。 


1. 单一 数据 源 
在 传统 的 MVC 架构 中 , 我 们 可 以 根据 需要 创建 无 数 个 














Model, 而 Model 之 间 可 以 互相 监听 、 


触发 事件 甚至 循环 或 欢 套 触发 事件 ， 这 些 在 Redux 中 都 是 不 允许 的 。 











因为 在 Redux 的 思想 里 , 一 个 应 用 永远 只 有 唯 
一 个 复杂 应 用 ， 强 制 要 求 唯一 的 数据 源 岂 不 是 会 


下 妆 
实际 上 , 使 用 单一 数据 源 的 好 处 在 于 整个 应 月 





十 
上 











的 数据 源 。 我 们 的 第 一 反应 可 能 是 : 如 果 有 
产生 一 个 特别 庞大 的 JavaScript 对 象 。 


状态 都 保存 在 一 个 对 象 中 ,这 样 我 





门 随时 可 以 


提取 出 整个 应 用 的 状态 进行 持久 化 ( 比如 实现 一 个 针对 整个 应 用 的 即时 保存 功能 ) 此外， 这样 


的 设计 也 为 服务 端 演 染 提供 了 可 能 。 
至 于 我 们 担心 的 数据 源 对 象 过 于 庞大 的 问题 ， 可 以 在 5 
combineReducers 是 如 何 化 解 的 。 
2. 状态 是 只 读 的 
这 一 点 和 Flux 的 思想 不 谋 而 合 ， 不 同 的 是 在 Flux 中 ， 





























.6.8 节 中 看 到 Redux 提供 的 工具 函数 


因为 store 没有 setter 而 限制 了 我 们 直 





接 修 改 应 用 状态 的 能 力 , 而 在 Redux 中 , 这 样 的 限制 被 执行 得 更 加 彻底 , 因为 我 们 压根 没有 store。 





在 Redux 中 ,我 们 并 不 会 自己 用 代码 来 定义 一 个 store。 昌 
它 的 功能 是 根据 当前 触发 的 action 对 当前 应 用 的 状态 (state 








取而代之 的 是 ,我 们 定义 一 个 reducer， 
) 进行 迭代 ， 这 里 我 们 并 没有 直接 修 
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改 应 用 的 状态 ， 而 是 返回 了 一 份 全 新 的 状态 。 

Redux 提供 的 createStore 方法 会 根据 reducer 生成 store。 最 后 , 我们 可 以 利用 store. dispatch 
方法 来 达到 修改 状态 的 目的 。 

3. 状态 修改 均 由 纯 函 数 完 成 

这 是 Redux 与 Flux 在 表现 上 的 最 大 不 同 。 在 Flux 中 ， 我 们 在 actionCreator 里 调用 
AppDispatcher .dispatch 方法 来 触发 action ,这 样 不 仅 有 宛 余 的 代码 , 而且 因为 直接 修改 了 store 中 
的 数据 ， 将 导致 无 法 保存 每 次 数据 变化 前 后 的 状态 。 

在 Redux 里 ， 我 们 通过 定义 reducer 来 确定 状态 的 修改 ， 而 每 一 个 reducer 都 是 纯 函 数 ， 这 意 
味 着 它 没 有 副作用 ， 即 接受 一 定 的 输入 ， 必 有 定 会 得 到 一 定 的 输出 。 

这 样 设 计 的 好 处 不 仅 在 于 reducer 里 对 状态 的 修改 变 得 简单 、 纯 粹 、 可 测试 ， 更 有 意思 的 是 ， 
Redux 利用 每 次 新 返回 的 状态 生成 酷 炫 的 时 间 旅 行 (time travel ) 调试 方式 , 让 跟踪 每 一 次 因为 触 
发 action 而 改变 状态 的 结果 成 为 了 可 能 。 




















5.1.3 Redux 核心 API 


Redux 的 核心 是 一 个 store , 这 个 store 由 Redux 提供 的 createStore(reducers[，, initiaLState]) 
方法 生成 。 从 函数 签名 看 出 ， 要 想 生 成 store， 必 须要 传人 reducers， 同 时 也 可 以 传人 第 二 个 可 选 
参数 初始 化 状态 ( initialstate )。 

在 继续 了 解 createstore 之 前 , 让 我 们 先 认 识 一 下 reducers。 在 上 一 章 介绍 Flux 时 我 们 说 到 ， 
Flux 的 核心 思想 之 一 就 是 不 直接 修改 数据 ， 而 是 分 发 一 个 action 来 描述 发 生 的 改变 。 那 么 ,在 
Redux 里 由 谁 来 修改 数据 呢 ? 

在 Redux 里 ， 负 责 响 应 action 并 修改 数据 的 角色 就 是 reducer。reducer 本 质 上 是 一 个 函数 ， 
其 函数 签名 为 reducer (previousState, action) => newState。 可 以 看 出 ，reducer 在 处 理 action 的 
同时 ， 还 需要 接受 一 个 previousState 参数 。 所 以 ，reducer 的 职责 就 是 根据 previousstate 和 
action 计算 出 新 的 newState。 


在 实际 应 用 中 ，reducer 在 处 理 previousstate 时 ， 还 需要 有 一 个 特殊 的 非 空 判断 。 很 显然 ， 
reducer 第 一 次 执行 的 时 候 , 并 没有 任何 的 previousState, 而 reducer 的 最 终 职责 是 返回 新 的 state， 
因此 需要 在 这 种 特殊 情况 下 返回 一 个 定义 好 的 initialstate: 

// MyReducer.js 

const initialState = { 


todos: []， 
}; 
















































































// 我 们 定义 的 todos 这 个 reducer 在 第 一 次 执行 的 时 候 ， 会 返回 { todos: [] } 作为 初始 化 状态 
function todos(previousState = initialState, action) { 
switch (action.type) { 


5.1] Redux 简介 2 





case 'XXX': { 
// 具体 的 业务 还 辑 


default: 
return previousState; 
} 
} 
根据 Dan Abramov 的 说 法 ，Redux 这 个 名 字 就 是 来 源 于 Reduce+Flux， 可 见 reducer 在 整个 


Redux 架构 中 拥有 举足轻重 的 作用 。 
下 面 就 是 Redux 中 最 核心 的 API 











createStore: 


import { createStore } from 'redux'; 
const store = createStore(reducers); 


通过 createStore 方法 创建 的 store 是 一 个 对 象 ， 它 本 身 又 包含 4 个 方法 。 
口 getState() : 获取 store 中 当前 的 状态 。 
口 dispatch(action) : 分 发 一 个 action， 并 返回 这 个 action， 这 是 唯一 能 改变 store 中 数据 的 
方式 。 
口 subscribe(Listener) : 注册 一 个 监听 者 ， 它 在 store 发 生变 化 时 被 调用 。 
口 repLaceReducer(nextReducer) : 更 新 当前 store 里 的 reducer， 一 般 只 会 在 开发 模式 中 调用 
该 方法 。 
在 实际 使 用 中 , 我 们 最 常用 的 是 getstate() 和 dispatch() 这 两 个 方法 。 至 于 subscribe() 和 
repLaceReducer() 方 法 ， 一 般 会 在 Redux 与 某 个 系统 (如 React ) 做 桥接 的 时 候 使 用 。 


关于 这 4 个 方法 的 具体 作用 和 实现 ， 请 参考 6.5 节 。 






































5.1.4 与 React 绑 定 


前 面 说 到 Redux 的 核心 只 有 一 个 createStore() 方法 ,但 是 仅仅 使 用 这 个 方法 还 不 足以 让 
Redux 在 我 们 的 React 应 用 中 发 挥 作用 。 我 们 还 需要 react-redux 库 Redux 官方 提供 的 React 
绑 定 。 

很 多 刚刚 接触 React 和 Redux 的 开发 者 可 能 会 好 奇 ， 明 明 有 了 Redux ， 为 什么 还 需要 
react-rfedux， 为 什么 不 把 它们 放 在 一 起 ?” 事实 上 ， 这 是 一 种 前 端 框架 或 类 库 的 架构 趋势 ， 即 尽 可 
能 做 到 平台 无 关 ( platform agnostic )。 我 们 在 第 1 章 中 也 提 到 过 ， 即 便 是 React， 也 在 0.14 版 本 之 
后 拆 分 了 React 和 ReactDOM 两 个 库 。 这 样 拆 分 的 好 处 在 于 ， 一 个 类 库 从 核心 逻辑 上 、 具 体 与 平 
台 相 关 的 实现 上 这 两 个 层面 做 了 拆 分 ， 能 保证 核心 功能 做 到 最 大 程度 的 跨 平台 复 用 。 

react-redux 提供 了 一 个 组 件 和 一 个 API 帮助 Redux 和 React 进行 绑 定 ， 一 个 是 React 组 件 
<Provider/> ,一 个 是 connect()。 关 于 它们 ， 只 需要 知道 的 是 ，<Provider/> 接受 一 个 store 作为 
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props， 它 是 整个 Redux 应 用 的 顶层 组 件 ， 而 connect() 提供 了 在 整个 React 应 用 的 任意 组 件 中 获 
取 store 中 数据 的 功能 。 


关于 这 两 个 方法 ,在 6.6 节 中 会 有 更 详细 的 介绍 。 


5.1.5 ”增强 Flux 的 功能 


我 们 在 上 一 章 中 提 到 ,Flux 的 一 个 很 大 的 不 足 在 于 定义 的 模式 太 过 松散 , 这 导致 许多 采用 了 
Flux 模式 的 开发 者 在 实际 开发 过 程 中 遇 到 一 个 很 纠结 的 问题 : 在 哪里 发 请 求 , 如 何 处 理 异 步 流 ? 

在 Redux 中 ， 这 种 异步 action 的 需求 可 以 通过 Redux 原生 的 middleware 设计 来 实现 。 在 
5.2 节 中 ， 我 们 将 看 到 更 多 关于 Redux middleware 的 介绍 与 使 用 。 


正如 Redux 官方 代码 库 的 介绍 中 所 说 ，Redux 是 一 个 可 预测 的 状态 容器 (predictable state 
container )。 简 单 地 说 ， 在 握 弃 了 传统 MVC 的 发 布 /订阅 模式 并 通过 Redux 三 大 原则 强化 对 状态 
的 修改 后 ， 使 用 Redux 可 以 让 你 的 应 用 状态 管理 变 得 可 预测 、 可 追溯 。 在 5.6 节 中 ， 我 们 会 以 一 
个 完整 的 例子 来 展示 Redux 应 用 是 如 何 帮 助 我 们 优化 数据 修改 过 程 以 及 梳理 数据 流动 方式 的 。 
































5.2 Redux middleware 


“It provides a third-party extension point between dispatching an action, and the moment it reaches 


the reducer.” 


这 是 Dan Abramov 对 middleware 的 描述 。 它 提供 了 一 个 分 类 处 理 action 的 机 会 。 在 
middleware 中 ， 你 可 以 检阅 每 一 个 流 过 的 action， 挑 选 出 特定 类 型 的 action 进行 相应 操作 ， 给 你 
一 次 改变 action 的 机 会 。 

















5.2.1 middleware 的 由 来 


5-2 表达 的 是 Redux 中 一 个 简单 的 同步 数据 流动 场景 ， 点 击 button 后 ， 在 回调 中 分 发 一 个 
action，reducer 收 到 action 后 ， 更 新 state 并 通知 view 重新 泻 染 。 单 向 数据 流 ， 看 着 没什么 问题 。 
但 是 ， 如 果 需 要 打印 每 一 个 action 信息 来 调试 ， 就 得 去 改 dispatch 或 者 reducer 实现 ， 使 其 具有 
打印 日 志 的 功能 。 又 比如 ， 点击 button 后 , 需要 先 去 服务 端 请 求 数据 ， 只 有 等 数据 返回 后 ,才能 
重新 泻 染 view， 此 时 我 们 希望 dispatch 或 reducer 拥有 异步 请 求 的 功能 。 再 比如 ， 需 要 异步 请 求 
数据 返回 后 ， 打 印 一 条 日 志 ， 再 请 求 数据 ， 再 打印 日 志 ， 再 泻 梁 。 


callback action state 
button 二 一 全 dispatch reducer a View 


图 5-2 ”Redux 同步 数据 流动 
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面 对 多 样 的 业务 场景 ， 单 纯 地 修改 dispatch 或 reducer 的 代码 显然 不 具有 普 适 性 ， 我 们 需要 
的 是 可 以 组 合 的 、 自 由 插 拔 的 插件 机 制 ， 这 一 点 Redux 借鉴 了 Koa ( 它 是 用 于 构建 Web 应 用 的 
Node.js 框架) 里 middleware 的 思想 ,详情 可 查阅 附录 A。 男 外 ，Redux 中 reducer 更 关心 的 是 数 
据 的 转化 逻辑 ， 所 以 middleware 就 是 为 了 增强 dispatch 而 出 现 的 。 

图 5-3 展示 了 应 用 middleware 后 Redux 处 理事 件 的 逻辑 ， 每 一 个 middleware 处 理 一 个 相对 
Ts 通过 串联 不 同 的 middleware 实现 变化 多 样 的 功能 。 那 么 ， 后 续 我 们 就 来 讨论 
middleware 是 怎么 写 的 ， 以 及 Redux 是 如 何 让 middleware 串联 起 来 的 。 







































































new dispatch 


aa action [人 
button midl mid2 dispatch reducer 


图 5-3 应 用 middleware 后 Redux 处 理事 件 的 逻辑 








5.2.2 ”理解 middleware 机 制 


Redux 提供 了 applyMiddleware 方法 来 加 载 middleware， 该 方法 的 源码 如 下 : 
import Compose from './compose'; 


export default function applyMiddleware(...middlewares) { 
return (next) => (reducer, initialState) => { 
let store = next(reducer, initialState); 
let dispatch = store.dispatch; 
let chain = []; 


var middlewareAPI = { 
getState: store.getState, 
dispatch: (action) => dispatch(action), 
}; 
chain = middlewares.map(middleware => middleware(middlewareAPI)); 
dispatch = compose(...chain)(store.dispatch); 


return { 
..Store, 
dispatch, 
}; 
} 
} 


applyMiddleware 的 代码 虽然 只 有 二 十 多 行 ， 却 非常 精炼 。 
然后 再 来 看 logger middleware 的 实现 : 


export default store => next => action => { 
console.log('dispatch:', action); 
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next(action); 
console.log('finish:', action); 


} 
接 下 来 ,我 们 就 分 4 步 来 深入 解析 middleware 的 运行 原理 。 


说 明 Redux 的 代码 都 是 用 ES6/ES7 写 的 ， 不 熟悉 store => next => action => 人 或...state 
的 读者 ， 可 以 先 学 习 下 箭头 函数 "和 展开 运算 符 >。 


1. 函数 式 编程 思想 设计 

middleware 的 设计 有 点 特殊 ， 是 一 个 层 层 包 囊 的 匿名 函数 ， 这 其 实 是 函数 式 编 程 中 的 
currying, 它 是 一 种 使 用 匿名 单 参数 函数 来 实现 多 参数 函数 的 方法 ,applyMiddleware 会 对 logger 这 
个 middleware 进行 层 层 调用 ， 动 态 地 将 store 和 next 参数 赋值 。 

currying 的 middleware 结构 的 好 处 主要 有 以 下 两 点 。 


口 易 串 联 : currying 函数 具有 延迟 执行 的 特性 ， 通 过 不 断 currying 形成 的 middleware 可 以 累 
积 参 数 ， 再 配合 组 合 (compose ) 的 方式 ， 很 容易 形成 pipeline 来 处 理 数据 流 。 

口 共享 store: 在 applyMiddleware 执行 的 过 程 中 ，store 还 是 旧 的 ， 但 是 因为 闭 包 的 存在 ， 
applyMiddleware 完成 后 ， 所 有 的 middleware 内 部 拿 到 的 store 是 最 新 且 相 同 的 。 


另外 ， 我 们 会 发 现 applyMiddleware 的 结构 也 是 一 个 多 层 currying 的 函数 。 借 助 compose， 
appLyMiddteware 可 以 用 来 和 其 他 插件 加 强 createStore 函数 : 















































import { createStore, applyMiddleware, compose } from "Redux '; 
import rootReducer from '../reducers'; 
import DevTools from '../containers/DevTools'; 


const finalCreateStore = Compose( 
// 在 开发 环境 中 使 用 的 middleware 
applyMiddleware(d1, d2, d3), 
// 它 会 启动 Redux DevTools 
DevTools.instrument() 
)(createStore); 


2. 给 middleware 分 发 store 
通过 如 下 方式 创建 一 个 普通 的 store : 
let newStore = applyMiddleware(mid1i, mid2, mid3, ...)(createStore)(reducer, null); 


上 述 代码 执行 完 后 ，applyMiddleware 方法 陆续 获得 了 3 个 参数 ， 第 一 个 是 middlewares 数组 
[midi, mid,, mtdj，...]， 第 二 个 是 Redux 原生 的 createStore ， 最 后 一 个 是 reducer。 然 后 ， 我 
































> 


GD Arrow functions， 详 见 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions。 
@ Spread operator， 详 见 https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Operators/Spread_operator。 
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们 可 以 看 到 applyMiddleware 利用 createStore 和 reducer 创建 了 一 个 store。 而 store 的 getState 
方法 和 dispatch 方法 又 分 别 被 直接 和 间接 地 赋值 给 middlewareAPI 变量 store: 





Const middlewareAPI = { 
getState: store.getState, 
dispatch: (action) => dispatch(action), 


}; 

chain = middlewares.map(middleware => middleware(middlewareAPI)); 

然后 , 让 每 个 middleware 带 着 middlewareAPI 这 个 参数 分 别 执行 一 遍 。 执行 完 后 , 获得 chaiin 
数组 [fi ， f,, 人 位 5 入 全 7 雪 f,] 交 它 保存 的 对 象 是 第 二 个 箭头 函数 返回 的 匿名 函数 。 因为 是 闭 
包 ， 每 个 匿名 函数 都 可 以 访问 相同 的 store， 即 middlewareAPI。 

















说 明 middlewareAPI 中 的 dispatch 为 什么 要 用 匿名 水 数 包 衰 呢 ? 
我 们 用 applyMiddleware 是 为 了 改造 dispatch, 所 以 applyMiddleware 执行 完 后 ,dispatch 是 
变化 了 的 ， 而 middLewareAPI 是 appLyMiddLeware 执行 中 分 发 到 各 个 middleware 的 ， 所 以 
必须 用 匿名 函数 包 训 dispatch， 这 样 只 要 dispatch 更 新 了 ，middlewareAPI 中 的 dispatch 应 
用 也 会 发 生变 化 。 


3. 组 合 串联 middleware 
这 一 层 只 有 一 行 代 码 ， 却 是 applyMiddleware 精华 之 所 在 : 
dispatch = compose(...chain)(store.dispatch); 


其 中 compose 是 函数 式 编程 中 的 组 合 ， 它 将 chain 中 的 所 有 匿名 函数 [fi, fi, ... ,fx ..., f,] 
组 装 成 一 个 新 的 函数 ， 即 新 的 dispatch。 当 新 dispatch 执行 时 ,， [fi, fi，... ，f，...，f]， 从 
右 到 左 依次 执行 。Redux 中 compose 的 实现 是 下 面 这 样 的 ， 当 然 实 现 方 式 并 不 唯 


function compose(...funcs) { 
return arg => funcs.reduceRight((composed, f) => f(composed), arg); 


} 

compose(...funcs) 返回 的 是 一 个 匿名 函数 , 其 中 funcs 就 是 chain 数组 。 当 调用 reduceRight 
时 ， 依 次 从 funcs 数组 的 右 端 取 一 个 函数 fx 拿 来 执行 ，fx 的 参数 composed 就 是 前 一 次 fa 执 
行 的 结果 ， 而 第 一 次 执行 的 f (Cn 代表 chaiin 的 长 度 ) 的 参数 arg 就 是 store.dispatch。 所 以 ， 
当 compose 执行 完 后 ， 我 们 得 到 的 dispatch 是 这 样 的 ,假设 n = 3: 

dispatch = f1i(f2(f3(store.dispatch)))); 

这 时 调用 新 dispatch， 每 一 个 middleware 就 依次 执行 了 。 

4. 在 middleware 中 调用 dispatch 会 发 生 什么 

经 过 compose 后， 所 有 的 middleware 算是 串联 起 来 了 。 可 是 还 有 一 个 问题 ， 在 分 发 store 时 ， 








































































































216 第 5 章 深入 Redux 应 用 架构 





我 们 提 到 过 每 个 middleware 都 可 以 访问 store， 即 middlewareAPI 这 个 变量 ， 也 可 以 拿 到 store 的 
dispatch 属性 。 那 么 ， 在 middleware 中 调用 store.dispatch() 会 发 生 什 么 ， 和 调用 next() 有 区 
别 吗 ? 现在 我 们 来 说 明 两 者 的 不 同 : 


Const Logger = store => next => action => { 
console.log('dispatch:', action); 
next(action); 
console.log( 'finish:', action); 


}; 











Const Logger = store => next => action => { 
console.log('dispatch:', action); 
store.dispatch(action); 
console.log( 'finish:', action); 


}; 

在 分 发 store 时 我 们 解释 过 ，middleware 中 store 的 dispatch 通过 匿名 函数 的 方式 和 最 终 
compose 结束 后 的 新 dispatch 保持 一 致 ， 所 以 ， 在 middleware 中 调用 store.dispatch() 和 在 其 他 
任何 地 方 调用 的 效果 一 样 。 而 在 middleware 中 调用 next() ， 效 果 是 进入 下 一 个 middleware， 如 
图 5-4 所 示 。 
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图 5-4 Redux middleware 流程 图 


正常 情况 下 ， 如 图 5-4 左 图 所 示 ， 当 我 们 分 发 一 个 action 时 ，middleware 通过 next(action) 
一 层 层 处 理 和 传递 action 直到 Redux 原生 的 dispatch。 如 果 某 个 middleware 使 用 store.dispatch 
(action) 来 分 发 action， 就 发 生 了 如 图 5-4 右 图 所 示 的 情况 ， 这 相当 于 重新 来 一 遍 。 假 如 这 个 
middleware 一 直 简 单 粗暴 地 调用 store.dispatch(action) ， 就 会 形成 无 限 循环 了 。 那 么 
store.dispatch(action) 的 用 武之 地 在 哪里 呢 ? 


假如 我 们 需要 发 送 一 个 异步 请 求 到 服务 端 获 取 数 据 ， 成 功 后 弹出 一 个 自 定 义 的 message。 这 
里 我 们 用 到 了 Redux Thunk: 























Const thunk = store => next => action => 
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typeof action === 'function' ? 
action(store.dispatch, store.getState) : 
next(action) 





Redux Thunk 会 判断 action 是 否 是 函数 。 如 果 是 ， 则 执行 action， 否 则 继续 传递 action 到 下 
一 个 middleware。 针 对 于 此 ， 我 们 设计 了 以 下 action: 


const getThenShow = (dispatch, getState) => { 
const url = 'http://xxx.json'; 


fetch(url) 
.then((response) => { 
dispatch({ 
type: 'SHOW_MESSAGE_FOR_ME', 
message: response.json(), 


}); 


}) 
.Catch(() => { 
dispatch({ 
type: 'FETCH_DATA_FAIL', 
message: 'error', 
]); 
]); 

}; 

这 时 候 只 要 在 应 用 中 调用 store.dispatch(getThenShow), Redux Thunk 就 会 执行 getThenShow 
方法 。getThenshow 会 先 请 求 数据 ， 如 果 成 功 ,分 发 一 个 显示 message 的 action; 和 否则， 分 发 一 个 
请 求 失 败 的 action。 而 这 里 的 dispatch 就 是 通过 Redux Thunk middleware 传递 进来 的 。 

在 middleware 中 使 用 dispatch 的 场景 一 般 是 接受 到 一 个 定向 action， 这 个 action 并 不 希望 到 

达 原 生 的 分 发 action , 往往 用 在 异步 请 求 的 需求 里 ,在 下 一 节 中 ,我 们 会 详细 讨论 如 何在 Redux 中 


实现 异步 流 。 
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曾经 前 端的 革新 是 以 Ajax 的 出 现 为 分 水 岭 ， 现 代 应 用 中 绝 大 部 分 页 面 泻 染 会 以 异步 流 的 方 
式 进行 。 我 们 还 记得 在 Flux 中 ， 并 没有 定义 在 哪里 发 异步 请 求 ， 那 么 是 如 何 解决 这 个 问 
题 的 呢 ? 








shy 

















5.3.1 使 用 middleware 简化 异步 请 求 
在 这 一 节 中 ， 我 们 通过 介绍 最 常用 的 3 个 middleware 来 介绍 Redux 怎样 发 异步 请 求 。 

















1. redux-thunk 


我 们 试想 ， 如 果 要 发 异步 请 求 ， 在 Redux 定义 中 ， 最 合适 的 位 置 是 在 action creator 中 实现 。 
但 我 们 之 前 了 解 到 的 action 都 是 同步 情况 ， 那 么 怎样 让 action 支持 异步 情况 呢 ? 
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这 里 引入 了 redux-thunk middleware。 首 先 我 们 需要 知道 什么 是 thunk? 
时 , 已 经 接触 并 熟悉 Thunk 函数 了 。 比 如 ; 





其 实在 学 习 Nodejs 


fs.readFile(fileName, callback); 


var readFileThunk = Thunk(fileName); 
readFileThunk(callback); 


var Thunk = function(fileName) { 
return function(callback) { 
return fs.readFile(fileName, callback); 


> 
}; 
Thunk 函数 实现 上 就 是 针对 多 参数 的 currying 以 实现 对 函数 的 惰性 求 值 。 任 何 函数 ， 只 要 参 
数 有 回调 函数 ， 就 能 写成 Thunk 函数 的 形式 。 


我 们 再 来 看 看 redux-thunk 的 源 代码 : 





function createThunkMiddleware(extraArgument) { 
return ({ dispatch, getState }) => next => action => { 


if (typeof action === 'function') { 
return action(dispatch, getState, extraArgument); 
} 
return next(action); 
}; 
} 





我 们 很 清楚 地 看 到 ， 当 action 为 函数 的 时 候 ， 我 们 并 没有 调用 next 或 dispatch 方法， 而 是 
返回 action 的 调用 。 这 里 的 action 即 为 一 个 Thunk 函数 ， 以 达到 将 dispatch 和 getState 参数 
传递 到 函数 内 的 作用 。 


了 解 redux-thunk 的 原理 后 , 这 里 我 们 模拟 请 求 一 个 天 气 的 异步 请 求 。action 通常 可 以 这 么 写 : 











function getWeather(url, params) { 
return (dispatch, getState) => { 
fetch(url, params) 
.then(result => { 
dispatch({ 
type: 'GET_WEATHER_SUCCESS', 
payload: result, 
}); 
}) 
.Catch(err => { 
dispatch({ 
type: 'GET_WEATHER_ERROR', 
error: err, 
}); 
}); 
}; 
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我 们 顺利 地 把 同步 action 变 成 了 异步 action。 


尽管 我 们 利用 Thunk 可 以 完成 各 种 复杂 的 异步 action， 但 是 对 于 某 些 复杂 但 是 又 有 规律 的 
场景 ， 抽 离 出 更 合适 的 、 目 标 更 明确 的 middleware 来 解决 会 是 更 好 的 方案 ， 而 异步 请 求 绝 对 


是 其 一 。 




















2. redux-promise 

我 们 发 现 ， 异 步 请 求 其 实 都 是 利用 promise 来 完成 的 ， 那 么 为 什么 不 通过 抽象 promise 来 解 
决 异步 流 的 问题 呢 ? 

这 里 再 引入 redux-promise middleware， 然 后 通过 源码 来 分 析 一 下 它 是 怎么 做 的 : 








import { isFSA } from 'flux-standard-action'; 


function ispromise(val) { 
return val && typeof val.then === 'function'; 


3 


export default function promiseMiddleware({ dispatch }) { 
return next => action => { 
if (!isFSA(action)) { 
return isPpromise(action) 
? action.then(dispatch) 
: next(action); 


} 


return ispromise(action.payload) 
? action.payload.then( 
result => dispatch({ ...action, payload: result })， 


error => { 
dispatch({ ...action, payload: error, error: true }); 
return Promise.reject(error); 

} 

) 
: next(action); 
}; 
} 

















redux-promise 兼容 了 FSA 标准 ， 也 就 是 说 将 返回 的 结果 保存 在 payload 中 。 实 现 过 程 非常 
容易 理解 ， 即 判断 action 或 action.payload 是 否 为 promise， 如 果 是 ， 就 执行 then， 返 回 的 结 
再 发 送 一 次 dispatch。 


我 们 利用 ES7 的 async 和 await 语法 ， 可 以 简化 上 述 异 步 过 程 : 



































const fetchData = (url, params) => fetch(url, params); 


async function getWeather(url, params) { 
const result = await fetchData(url, params); 


if (result.error) { 
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return { 
type: 'GET_WEATHER_ERROR', 
error: result.error, 
}; 
} 


return { 

type: 'GET_WEATHER_SUCCESS', 
payload: result, 

}; 
} 


3. redux-composable-fetch 
在 实际 应 用 中 ， 我 们 还 需要 加 上 loading 状态 。 结 合 上 述 讨论 的 两 个 开源 middleware ， 我 们 
完全 可 以 自己 实现 一 个 更 贴 合 工程 需要 的 middleware， 这 里 将 其 命名 为 redux-composable-fetch。 
在 理想 情况 下 , 我 们 不 希望 通过 复杂 的 方法 去 请 求 数据 ,而 希望 通过 如 下 形式 一 并 完成 在 异 
步 请 求 过 程 中 的 不 同 状态 : 
{ 
url: '/api/weather .json', 


params: { 
city: encodeURI(city), 


J} 
types: ['GET_WEATHER', 'GET_WEATHER_SUCESS', 'GET_WEATHER_ERROR'], 

















可 以 看 到 ， 异 步 请 求 action 的 格式 有 别 于 FSA。 它 并 没有 使 用 type 属性 ， 而 使 用 了 types 属 
生 。types 其 实 是 三 个 普通 action type 的 集合 ， 分 别 代表 请 求 中 、 请 求 成 功 和 请 求 失 败 。 

在 请 求 middleware 中 ， 会 对 action 进行 格式 检查 ， 若 存在 url 和 types 属性 ， 则 说 明 这 个 
action 是 一 个 用 于 发 送 异 步 请 求 的 action。 此 外 ， 并 不 是 所 有 请 求 都 能 携带 参数 ， 因 此 params 是 
可 选 的 。 

当 请 求 middleware 识别 到 这 是 一 个 用 于 发 送 请 求 的 action 后 ， 首 先 会 分 发 一 个 新 的 action ， 
这 个 action 的 type 就 是 原 action 里 types 数组 中 的 第 一 个 元 素 ， 即 请 求 中 。 分 发 这 个 新 action 的 
目的 在 于 让 store 能 够 同步 当前 请 求 的 状态 ， 如 将 loading 状态 置 为 true， 这 样 在 对 应 的 界面 上 可 
以 展示 一 个 友好 的 加 载 中 动画 。 

然后 ， 请 求 middleware 会 根据 action 中 的 urL、params 、method 等 参数 发 送 一 个 异步 请 求 ， 
并 在 请 求 响应 后 根据 结果 的 成 功 或 失败 分 别 分 发 请 求 成 功 或 请 求 失 败 的 新 action。 

请 求 middleware 的 简化 实现 如 下 ， 我 们 可 以 根据 具体 的 场景 对 此 进行 改造 : 






























































const fetchMiddleware = store => next => action => { 
if (!action.url || !Array.isArray(action.types)) { 
return next(action); 


} 
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const [LOADING, SUCCESS, ERROR] = action.types; 


next({ 
type: LOADING, 
loading: true, 
...action， 


]); 


fetch(action.url, { params: action.params }) 
.then(result => { 
next({ 
type: SUCCESS, 
loading: false, 
payload: result, 
]); 
}) 
.Catch(err => { 
next({ 
type: ERROR, 
loading: false, 
error: err, 
]); 
]); 
} 


这 样 我 们 的 确 一 步 就 完成 了 异步 请 求 的 action。 





5.3.2 ”使 用 middleware 处 理 复杂 异步 流 | 
在 实际 场景 中 ,我 们 不 但 有 短 连接 请 求 ,， 还 有 和 轮 询 请 求 、 多 异步 串联 请 求 ,或 是 在 异步 中 加 
人 和信 同步 处 理 的 逻辑 。 这 时 候 ， 使 用 redux-composable-fetch 就 显得 力不从心 了 。 
1. 轮 询 
轮 询 是 长 连接 的 一 种 实现 方式 ， 它 能 够 在 一 定时 间 内 重新 启动 自身 ， 然 后 再 次 发 起 请 求 。 基 
于 这 个 特性 ， 我 们 可 以 在 redux-composable-fetch 的 基础 上 再 写 一 个 middleware， 这 里 命名 为 
redux-polling: 




















import setRafTimeout, { clearRafTimeout } from 'setRafTimeout'; 


export default ({ dispatch, getState }) => next => action => { 
const { pollingUrl, params, types } = action; 
const isPollingAction = pollingUrl && params && types; 


if (!ispollingAction) { 
return next(action); 


3. 


let timeoutId = null; 
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const startPolling = (timeout = 0) => { 
timeoutId = setRafTimeout(() => { 
const { pollingUrl, ...others } = action; 


const pollingAction = { 
.. .0thers, 
url: pollingUrl, 
timeoutId, 
}; 
dispatch(pollingAction).then(data => { 
if (data && data.interval && typeof data.interval === 'number') { 
startPoLLing(data.intervaL * 1000); 


} else 并 
console.error('pollingAction should fetch data contain intervatL ' ) ; 


} 
]); 


}, timeout); 


}; 


startPpolling(); 
} 


export const clearPollingTimeout = (timeoutId) => { 


if (timeoutId) { 
clearRafTimeout(timeoutId); 


} 
}; 
在 这 个 middleware 的 实现 中 ,我们 用 到 了 raf 函数 ， 在 2.7 节 中 我 们 已 经 提 到 过 它 。raf 是 
实现 中 的 关键 点 之 一 ， 它 可 以 让 请 求 在 一 定时 间 内 重新 发 起 。 
另外 , 在 API 的 设计 上 ， 我 们 还 暴露 了 clearPollingTimeout 方法 ， 以 便 我 们 在 需要 时 手动 
停止 轮 询 。 
最 后 ， 调 用 action 来 发 起 轮 询 : 

















{ 
pollingUrl: '/api/weather.json', 
params: { 
city: encodeURI(city), 
}, 


types: [null, 'GET_WEATHER_SUCESS', null], 





至 于 长 连接 , 还 有 其 他 多 种 实现 方式 , 最 好 的 方式 是 对 其 整体 做 一 次 封装 ,在 内 部 实现 诸如 
轮 询 和 WebSocket。 


2. 多 异步 串联 
多 异步 串联 是 我 们 在 应 用 场景 中 常见 的 逻辑 , 根据 以 往 的 经 验 , 是 不 是 很 快 就 想到 用 promise 


去 实现 。 
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我 们 试想 ， 通 过 对 promise 封装 是 不 是 能 够 做 到 不 论 是 否 是 异步 请 求 ， 都 通过 promise 来 传 
递 以 达到 一 个 统一 的 效果 。 的 确 ， 这 一 点 非常 容易 就 可 以 实现 ; 
Const sequenceMiddleware = ({dispatch, getState}) => next => action => { 
if (!Array.isArray(action)) { 


return next(action); 


} 


return action.reduce( (result, currAction) => { 
return result.then(() => { 
return Array.isArray(currAction) ? 
Promise.all(currAction.map(item => dispatch(item))) : 
dispatch(currAction); 


]); 


}, Promise.resolve()); 


} 

这 里 我 们 定义 了 一 个 名 为 sequenceMiddleware 的 middleware。 在 构建 action creator 时 ， 会 传 
递 一 个 数组 , 数组 中 每 一 个 值 都 将 是 按 顺 序 执行 的 步骤 。 这 里 的 步骤 既 可 以 是 异步 的 , 也 可 以 是 
同步 的 。 

在 实现 过 程 中 ， 我 们 非常 巧妙 地 使 用 Promise.resolve() 来 初始 化 action.reduce 方法 ， 然 
后 始终 使 用 Promise.then() 方法 串联 起 数组 ， 达 到 了 串联 步骤 的 目的 。 

这 里 还 是 使 用 之 前 的 例子 。 假 设 我 们 的 应 用 初始 化 时 会 先 获 取 当 前 城市 ,然后 获取 当前 城市 
的 天 气 信息 ， 那 么 就 可 以 这 么 写 : 



































function getCurrCity(ip) { 
return { 
url: '/api/getCurrCity.json', 
params: { ip }, 
types: [null, 'GET_CITY_SUCCESS', null], 
} 
} 


function getWeather(cityId) { 

return { 
url: '/api/getWeatherInfo.json', 
params: { cityId }, 
types: [null, 'GET_WEATHER_SUCCESS', null], 
}; 
} 


function loadInitData(ip) { 
return [ 
getCurrCity(ip), 
(dispatch, state) => { 
dispatch(getWeather(getCityIdwithsState(state))); 
}， 
J; 
} 
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这 种 方法 利用 了 数组 的 特性 。 可 以 看 到 , 它 已 经 覆盖 了 大 部 分 场景 。 当 然 ， 如 果 串 联 过 程 中 
有 不 同 的 分 文 ， 就 无 能 为 力 了 。 

3. redux-saga 

在 Redux 社区 ， 还 有 一 个 处 理 异步 流 的 后 起 之 秀 ， 名 为 redux-saga。 它 与 上 述 方法 最 直观 的 
不 同 就 是 用 generator 替代 了 promise， 我 们 通过 Babel 可 以 很 方便 地 支持 generator: 


function* getCurrCity(ip) { 
const data = yield call('/api/getCurrCity.json', { ip }); 











yield put({ 
type: 'GET_CITY_SUCCESS', 
payload: data, 
}); 
} 


function* getWeather(cityId) { 
const data = yield call('/api/getWeatherInfo.json', { cityId }); 


yield put({ 
type: 'GET_NEATHER_SUCCESS ' ， 
payLoad: data， 
]); 
} 


function loadInitData(ip) { 
yield getCurrCity(ip); 
yield getWeather(getCityIdwithState(state)); 
yield put({ 
type: 'GET_DATA SUCCESS', 
}); 
} 


redux-saga 的 确 是 最 优雅 的 通用 解决 方案 ， 它 有 着 灵活 而 强大 的 协 程 机 制 ， 可 以 解决 任何 复 
杂 的 异步 交互 。 要 想 深入 学 习 redux-sage， 请 参考 官方 文档 。 











5.4 Redux 与 路 由 


要 开发 一 个 富 客户 端 应 用 ， 有 一 样 东西 是 必 不 可 少 的 一 一 路 由 (router ) 系统 。 

在 过 去 ， 路 由 是 服务 端 专 有 的 部 分 。 自 从 富 客 户 端 应 用 越 来 越 广泛 地 出 现在 Web 上 ， 我 们 
已 经 不 能 忽视 前 后 端 之 间 发 生 的 巨大 变化 。SPA 应 用 也 不 例外 , 可 以 说 ,所 有 SPA 都 必然 会 由 一 
个 路 由 系统 作为 整个 系统 的 入 口 。 

在 React 的 生态 环境 中 ，React Router 是 公认 的 最 优秀 的 路 由 解决 方案 。 它 提供 了 与 React 思 
想 十 分 贴 合 的 声明 式 的 路 由 系统 。 我 们 可 以 通过 <Router> 、<Route> 这 两 个 标签 以 及 一 系列 属性 
定义 整个 React 应 用 的 路 由 方案 。 

然而 在 Redux 应 用 中 , 我 们 遇 到 了 一 些 新 的 问题 。 其 中 最 迫切 的 问题 是 ,应 用 程序 的 所 有 状 
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态 都 应 该 保存 在 一 个 单一 的 store 中 ， 而 当前 的 路 由 状态 很 明显 也 属于 应 用 状态 的 一 部 分 。 如 果 
直接 使 用 React Router， 就 意味 着 所 有 路 由 相关 的 信息 脱离 了 Redux store 的 控制 ， 这 样 就 违背 了 
Redux 的 设计 思想 ， 也 给 我 们 的 应 用 带 来 了 更 多 的 不 确定 性 。 
所 以 ,我 们 需要 一 个 这 样 的 路 由 系统 ， 它 既 能 利用 React Router 的 声明 式 特性 ， 又 能 将 路 由 
信息 整合 进 Redux store 中 。 
本 节 中 ， 我 们 将 详细 为 大 家 介绍 React Router 和 react-router-redux 的 使 用 方式 、 工 作 原 理 及 
最 佳 实践 。 




















5.4.1 React Router 


我 们 知道 ,React 不 是 一 个 前 端 应 用 框架 ,因此 不 像 Angularjs 或 者 Ember.js 等 集成 了 开发 者 
可 能 需要 的 各 种 各 样 的 功能 , 你 必须 选择 符合 自己 需求 且 必 要 的 部 件 才能 打造 一 个 完整 的 前 端 单 
页 应 用 。 

而 说 到 和 React 应 用 搭配 的 路 由 系统 ， 非 React Router 莫 属 。 事 实 上 ，React Router 在 GitHub 
上 的 代码 库 已 经 和 React 一 样 都 归属 于 reactjs Group 下 。 从 某 种 意义 上 来 说 ，React Router 已 经 
成 为 官方 认证 的 路 由 库 了 。 

1. 路 由 的 基本 原理 

简单 地 说 ， 路 由 的 基本 原理 即 是 保证 View 和 URL 同步 ， 而 View 可 以 看 成 是 资源 的 一 种 表 
现 。 当 用 户 在 Web 界面 中 进行 操作 时 ， 应 用 会 在 若干 个 交互 状态 中 切换 ， 路 由 则 会 记录 下 某 些 
重要 的 状态 , 比如 在 博客 系统 中 用 户 是 否 登录 、 访问 哪 一 篇 文章 、 位 于 文章 归档 列表 的 第 几 页 等 。 

这 些 变 化 同样 会 被 记录 在 浏览 絮 的 历史 中 ,用 户 可 以 通过 浏览 絮 的 “前 进 ”"、“ 后 退 ” 按 钮 切换 
状态 ， 同 样 可 以 将 URL 分 享 给 好 友 。 简 单 地 说 ， 用 户 可 以 通过 手动 输入 或 者 与 页 面 进 行 交 互 来 改 
变 URL， 然 后 通过 同步 或 者 异步 的 方式 向 服务 端 发 送 请 求 获 取 资 源 ， 重 新 绘制 UI， 如 图 5-5 所 示 。 
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图 5-5 ”React Router 流程 图 





226 第 5 章 深入 Redux 应 用 架构 








那么 ，React Router 和 其 他 前 端 路 由 有 什么 区 别 呢 ? 
2. React Router 的 特性 


ReactRouter 中 的 很 多 特性 都 与 React 保持 一 致 。 回 想 一 下 , 在 React 中, 组 件 就 是 一 个 方法 。 
props 作为 方法 的 参数 ， 当 它们 发 生变 化 时 会 触发 方法 执行 ， 进 而 帮助 我 们 重新 绘制 View。 在 




















React Router 中 ， 我 们 同样 可 以 把 Router 组 件 看 成 一 个 方法 ，location 作为 参数 ， 返 回 的 结果 同 


location 





样 是 View， 如 图 5-6 所 示 。 








图 5-6 ”React Router 与 React 对 比 


@ 声明 式 的 路 由 

从 图 5-6 中 ， 我 们 很 自然 就 可 以 联想 到 ，React 带 给 我 们 最 特别 的 编程 体验 就 是 声明 式 编程 ， 
所 有 的 交互 逻辑 都 在 render 返回 的 JSX 标签 中 得 到 体现 。 而 ReactRouter 很 好 地 继承 了 React 的 
这 一 特点 ， 人 允许 开发 者 使 用 JSX 标签 来 书写 声明 式 的 路 由 。 下 面 是 一 个 简单 的 例子 : 


import { Router, Route, browserHistory } from 'react-router'; 












































Const routes = ( 
<Router history={browserHistory}> 
<Route path="/" component={App} /> 
</Router> 
); 
不 用 过 多 解释 ， 我 们 就 可 以 看 出 当前 页 面 url 为 / 时 ，React Router 会 帮 我 们 泻 染 App 这 个 
组 件 。 
当然 , 这 只 是 最 简单 的 路 由 情况 ,实际 应 用 中 路 由 配置 会 比 这 复杂 得 多 。 由 于 声明 式 标签 原 
生 的 表述 能 力 ， 我 们 依然 能 够 在 最 短 的 时 间 内 对 整个 应 用 的 路 由 设计 有 一 个 全 面 的 了 解 。 
@ 说 套路 由 及 路 径 匹 配 
在 许多 复杂 的 单 页 应 用 中 , 髓 套路 由 是 再 常见 不 过 的 设计 了 。 以 Gmail 为 例 ， 当 我 们 打开 首 
页 时 ,页 面 上 会 展示 一 个 顶 栏 、 一 个 侧 边 栏 和 一 个 收 件 箱 列表 。 而 当 点 击 某 封 具体 的 邮件 时 ， 界 
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面 上 依然 展示 了 项 栏 和 侧 边栏 ， 唯 一 不 同 的 是 收 件 箱 列 表 变 成 了 邮件 详情 。 
而 React Router 为 这 种 向 套 的 情况 提供 了 良好 的 支持 : 


import { Router, Route, IndexRoute, browserHistory } from 'react-router'; 





const routes = ( 
<Router history={browserHistory}> 
<Route path="/" component={App}> 
<IndexRoute component={MailList} /> 
<Route path="/mail/:mailIld" component={Mail} /> 
</Route> 
</Router> 
); 
在 这 个 路 由 配置 中 ，App 组 件 承 载 了 显示 顶 栏 和 侧 边 栏 的 功能 ， 而 React Router 会 根据 当前 


的 url 自动 判断 该 显示 邮件 列表 页 还 是 详情 页 : 
口 当 url 为 /时 ， 显示 列表 页 
口 当 urt 为 /mail/123 时 ， 品 示 详 情 页 。 

那么 ， 在 声明 路 由 的 时 候 ， 怎 么 知道 url 里 matLId 会 是 123 还 是 456 呢 ? 这 就 要 说 到 React 
Router 的 路 径 匹 配 特性 了 。 

在 声明 路 由 时 ，path 属性 指明 了 当前 路 由 匹配 的 路 径 形式 。 知 某 条 路 由 需要 参数 ， 只 用 简单 
地 加 上 :参数 名 即 可 。 知 这 个 参数 是 可 选 参数 ， 则 用 括号 套 起 来 (: 可 选 参数 )。 

@ 支持 多 种 路 由 切换 方式 

我 们 都 知道 路 由 切换 无 外 乎 使 用 hashchange 或 是 htstory.pushState。hashChange 的 方式 拥 
有 和 良好 的 浏览 器 兼容 性 ， 但 是 url 中 却 多 了 丑陋 的 /#/ 部 分 ; 而 history.pushstate 方法 则 能 给 
我 们 提供 优雅 的 urL， 却 需要 额外 的 服务 端 配 置 解决 任意 路 径 刷 新 的 问题 。 

因此 ，React Router 提供 了 两 种 解决 方案 供 你 根据 自己 的 业务 需求 进行 挑选 。 这 也 是 为 什么 
我 们 的 路 由 配置 中 需要 从 react-router 引入 browserHistory 并 将 其 当 作 props 传 给 Router 。 


browserHistory 即 history.pushstate 的 实现 ， 假 如 想 使 用 hashchange 的 方式 改变 路 由 ， 从 
React Router 中 使 用 import hashHistory 即 可 。 















































































































































5.4.2 React Router Redux 


在 Redux 刚刚 兴起 的 时 候 ， 社 区 中 就 出 现 了 与 之 配套 的 解决 方案 Redux Router， 它 基于 
React Router， 利 用 高 阶 组 件 的 概念 实现 了 路 由 状态 与 Redux store 的 绑 定 。 然 而 由 于 Redux 
Router 设计 得 非常 烦琐 ,引入 了 太 多 的 API, 所 以 学 习 和 整合 的 难度 太 大 , 逐渐 被 Redux Simple 
Router 所 取代 。 


然而 就 在 本 书 编写 时 ，ReactRouter 发 布 了 2.0.0 版 本 , 在 这 一 版 中 提供 了 对 Redux 应 用 的 支 
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持 。 同 时 ，Redux Simple Router 也 更 名 为 React Router Redux。 


既然 React Router 已 经 这 么 强大 ， 为 什么 我 们 还 需要 React Router Redux 呢 ? 正如 我 们 在 上 
一 章 中 提 到 的 ，React Router Redux 的 前 身 是 Redux Simple Router， 它 的 职责 主要 是 将 应 用 的 路 
信息 与 Redux 中 的 store 绑 定 在 一 起 。 你 可 能 会 好 奇 为 什么 要 这 么 做 ? 

答案 很 简单 。 因 为 对 于 前 端 应 用 来 说 ， 路 由 状态 ( 当前 切换 到 了 哪个 页 面 ， 当 前 页 面 的 参数 
有 了 哪些， 等 等 ) 也 是 应 用 状态 的 一 部 分 。 在 很 多 情况 下 ,我 们 的 业务 逻辑 与 路 由 状态 有 很 强 的 关 
联 关系 。 比 如 ， 最 常见 的 一 个 列表 页 中 ， 分 页 参数 、 排 序 参数 可 能 都 会 在 路 由 中 体现 ， 而 这 些 参 
数 的 改变 必然 导致 列表 中 的 数据 发 生变 化 。 

因此 ， 当 我 们 采用 Redux 架构 时 ， 所 有 的 应 用 状态 必须 放 在 一 个 单一 的 store 中 管理 
状态 也 不 例外 。 而 这 就 是 React Router Redux 为 我 们 实现 的 主要 功能 。 


1. 将 React Router 与 Redux store 绑 定 


React Router Redux 提供 了 简单 直 白 的 API syncHistorywithstore 来 完成 与 Redux store 
的 绑 定 工作 。 我 们 只 需要 传人 React Router 中 的 history ( 前面 提 到 的 browserHistory 或 
hashHistory， 其 至 是 自己 创建 的 history )， 以 及 Redux 中 的 store， 就 可 以 获得 一 个 增强 后 的 
history 对 象 。 

将 这 个 history 对 象 传 给 ReactRouter 中 的 <Router> 组 件 作为 props ,就 给 React Router Redux 
提供 了 观察 路 由 变化 并 改变 store 的 能 力 (反之 亦 然 ): 


import { browserHistory } from 'react-router’ 
import { syncHistoryWithStore } from 'react-router-redux' 
import reducers from '<project-path>/reducers' 
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const store = createStore(reducers); 
const history = syncHistoryWithStore(browserHistory, store); 


2. 用 Redux 的 方式 改变 路 由 

无 论 是 Flux 还 是 Redux， 想 要 改变 数据 ， 必 须要 分 发 一 个 action。 前 面 又 讲 到 了 ， 路 由 状态 
作为 应 用 状态 数据 的 必要 性 。 那么 , 在 Redux 应 用 中 需要 改变 路 由 时 , 是 不 是 也 要 分 发 一 个 action 
呢 ? 答案 是 肯定 的 。 

但 是 在 这 之 前 ， 我 们 需要 对 Redux 的 store 进行 一 些 增强 ， 以 便 分 发 的 action 能 被 正确 识别 : 


import { browserHistory } from 'react-router'; 
import { routerMiddleware } from 'react-router-redux'; 






































const middleware = routerMiddleware(browserHistory); 
const store = createStore( 

reducers, 

applyMiddleware(middleware) 

); 
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首先 , 我 们 引入 了 React Router Redux 提供 的 routerMiddleware, 它 实际 上 是 一 个 middleware 
工厂 ， 传 入 history 对 象 ， 返 回 一 个 真正 的 Redux middleware。 最 终 ， 在 创建 Redux store 时 ， 我 
们 将 这 个 middleware 启用 并 作为 第 二 个 参数 传人 createStore 方 法 ,获得 被 ReactRouter Redux 加 
工 过 的 新 store。 


最 后 ， 就 可 以 用 store.dispatch 来 分 发 一 个 路 由 变动 的 action 了 : 


import { push } from 'react-router-redux'; 





// 切换 路 由 到 /home 
store.dispatch(push('/home')); 


React Router 是 一 个 “多 变 ” 的 路 由 库 , 在 1.0 正式 版 之 前 ， 每 一 个 小 版 本 都 会 有 大 量 的 API 
变动 , 这 也 对 开发 者 们 的 开发 体验 造成 了 极 大 的 痛苦 。 但 不 论 它 怎么 变 ， 只 要 我 们 熟练 掌握 了 其 
中 的 原理 ， 就 可 以 以 不 变 应 万 变 。 











5.5 Redux 与 组 件 
我 们 在 4.1 节 中 提 到 了 两 种 类 型 的 组 件 ， 一 种 是 容器 型 组 件 ， 这 种 命名 在 第 1 章 中 提 到 过 ， 
另 一 种 是 展示 型 组 件 。 要 区 分 它们 ， 主 要 是 看 是 否 有 数据 操作 。 


在 早期 Redux 版 本 中 ， 作 者 将 上 述 两 种 组 件 定义 为 Smart 和 Dumb 组 件 ， 但 是 这 个 名 字 过 于 
用 涩 。 为 了 可 以 通过 名 字 清 晰 地 区 分 出 两 者 的 不 同 ， 新 名 字 就 应 运 而 生 了 。 


本 节 中 ,我 们 就 来 讨论 一 下 这 两 种 组 件 的 定义 与 应 用 场景 ， 以 及 与 Redux 的 关系 。 






































5.5.1 容器 型 组 件 
容器 型 组 件 ， 意 为 组 件 是 怎么 工作 的 ,更 具体 一 些 就 是 数据 是 怎么 更 新 的 。 它 不 会 包含 任何 
Virtual DOM 的 修改 或 组 合 ， 也 不 会 包含 组 件 的 样式 。 


如 果 有 映射 到 Flux 上 ， 那 么 容器 型 组 件 就 是 与 store 作 绑 定 的 组 件 。 如 果 映 射 到 Redux 上 ， 那 
么 容 妖 型 组 件 就 是 使 用 connect 的 组 件 。 因 此 ， 我 们 都 在 这 些 组 件 里 作 了 数据 更 新 的 定义 。 






























































5.5.2 ”展示 型 组 件 
展示 型 组 件 ， 意 为 组 件 是 怎么 浑 染 的 。 它 包含 了 Virtual DOM 的 修改 或 组 合 ， 也 可 能 包含 组 
件 的 样式 。 同 时 ， 它 不 依赖 任何 形式 的 store。 一 般 可 以 写成 无 状态 函数 ， 但 实际 上 展示 型 组 件 
并 不 一 定 都 是 无 状态 的 组 件 ， 因 为 很 多 展示 型 组 件 里 依然 存在 生命 周期 方法 。 
这 样 做 区 分 的 目的 是 为 了 可 以 使 用 相同 的 展示 型 组 件 来 配合 不 同 的 数据 源 作 泻 染 , 可 以 做 到 
更 好 的 可 复 用 性 。 另外, 展示 型 组 件 可 以 让 设计 师 不 用 关心 应 用 的 逻辑 , 去 随时 尝试 不 同 的 组 合 。 
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5.5.3 Redux 中 的 组 件 


关于 容 需 型 组 件 和 展示 型 组 件 ，Redux 官方 文档 给 出 了 对 比 


结 只 


， 如 表 5-1 所 示 。 



































表 5-1 对 比 容器 型 组 件 和 展示 型 组 件 
展示 型 组 件 容器 型 组 件 
目的 长 什么 样子 (标签 、 样 式 等 ) 干什么 用 (获取 数据 、 更 新 状态 等 ) 
是 否 感知 Redux 否 是 
要 获取 数据 从 this.props 中 获取 哆 用 connect 从 Redux 状态 树 中 获取 
要 改变 数据 调用 从 props 中 传人 的 action creator 直接 分 发 任意 action 
实际 创建 于 开发 者 自身 通常 由 React Redux 创建 





从 布局 的 角度 来 看 ， 在 Redux 中 ， 强 调 了 3 











种 不 同类 型 的 布局 组 件 : Layouts 、Views 和 























Components。 它 们 与 容器 型 组 件 和 展示 型 组 件 有 着 怎样 的 对 应 关系 呢 ? 

1. Layouts 

Layouts 指 的 是 页 面 布局 组 件 ， 描 述 了 页 面 的 基本 结构 ， 目 的 是 将 主 框架 与 页 面 主体 内 容 分 
离 。 它 常常 是 无 状态 函数 ， 传 人 主体 内 容 的 children 属性 。 结 合 5.4 节 的 内 容 ，Layout 组 件 就 是 
设置 在 最 外 层 Route 中 的 component 里 。 一 般 Layout 的 写法 如 下 : 


const Layout = ({ children }) => ( 
<div className='container'> 
<Header /> 
<div className="content"> 
{children} 
</div> 
</div> 


); 
2. Views 


Views 指 的 是 子路 由 入 口 组 件 ， 描 述 了 子路 
































入 口 的 基本 结构 ,包含 此 路 由 下 所 有 的 展示 型 


组 件 。 为 了 保持 子 组 件 的 纯净 ,我 们 在 这 一 层 组 件 中 定义 了 数据 和 action 的 入 口 ， 从 这 里 开始 将 




















它们 分 发 到 子 组 件 中 去 。 因 此 ，Views 就 是 Redux 


@connect((state) => { 
VA 
}) 
class HomeView extends Component { 
render() { 
const { sth, changeType } = this.props; 
const cardProps = { sth, changeType }; 


return ( 
<div className="page page-home"> 
<Card {...cardProps} /> 
</div> 
); 
} 
} 





中 的 容器 型 组 件 。 一 般 Views 的 写法 如 下 : 
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3. Components 


顾名思义 ，Components 就 是 未 级 泻 染 组 件 ， 描 述 了 从 路 由 以 下 的 子 组 件 。 它 们 包含 具体 的 
业务 逻辑 和 交互 ， 但 所 有 的 数据 和 action 都 是 由 Views 传 下 来 的 ， 这 也 意味 着 它们 是 可 以 完全 脱 
离 数 据 层 而 存在 的 展示 型 组 件 。 一 般 由 路 由 传 下 来 的 Components 的 写法 如 下 : 





class Card extends Components { 
constructor(props) { 
super(props); 





























this.handleChange = this.handleChange.bind(this); 


} 


handleChange(opts) { 
const { type } = opts; 


this.props.changeType(type); 
} 


render() { 
const { sth } = this.props; 


return ( 
<div className="mod-card"> 


<Switch onChange={this.handleChange}> 


A es 
</Switch> 
{sth} 
</div> 
); 
} 
} 


通过 上 述 3 种 组 件 的 定义 , 我 们 看 到 Redux 中 对 页 面 布局 的 区 分 , 以 及 页 面 的 基本 结构 与 数 





据 传 递 的 形式 。 这 么 做 是 为 了 更 好 


也 利用 React 组 件 的 可 复 用 性 。 








从 第 2 章 到 本 节 ， 我 们 对 于 React 组 件 的 解释 终于 趋 于 完整 。 对 于 我 们 来 说 ， 分 清楚 这 些 概 





念 尤为 重要 。 除 了 上 述 的 容 需 型 组 


| 件 和 展示 型 组 件 外 ， 还 有 有 状态 ( stateful ) 组 件 和 无 状态 


( stateless ) 组 件 、 类 (class ) 和 方法 (fonction )、 纯 (pure ) 组 件 和 非 纯 (impure ) 组 件 。 


5.6 ” Redux 应 用 实例 


为 了 充分 了 解 Redux 架构 在 实际 项 目 中 的 应 用 , 我 们 准备 了 一 个 全 新 的 Redux SPA 示例 一 一 
一 个 包含 文章 列表 和 文章 详情 等 页 面 的 简易 博客 系统 。 
在 这 个 示例 中 ， 我 们 将 会 接触 到 Redux 所 有 的 知识 点 ， 并 将 其 串联 在 一 起 作 完整 的 解释 。 


5.6.1 初始 化 Redux 项 目 
首先 ， 我 们 从 项 目 初始 化 说 起 。 








这 必须 从 新 建 目 录 开 始 。 新 建 redux-blog 目录 ， 用 于 保存 整 
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个 博客 系统 的 所 有 内 容 ， 包 括 源码 、 依 赖 、 构 建 脚本 等 : 

$ mkdir redux-blog && cd redux-blog 

像 初始 化 React 项 目 那 样 ， 我 们 需要 新 增 一 个 package.json 文件 ， 用 于 描述 项 目的 基本 信息 
以 及 项 目 需要 的 各 种 依赖 。 由 于 我 们 不 需要 将 这 个 项 目 发 布 给 其 他 人 使 用 , 所 以 在 初始 化 的 过 程 
中 不 需要 填写 太 多 信息 。 

接着 ,需要 安装 一 些 必要 的 依赖 : 

$ npm instaLL --save react react-dom redux react-router react-redux react-router-redux whatwg-fetch 

可 以 看 到 ， 除 了 最 基本 的 React、Redux 和 react-redux 外 ， 我 们 还 安装 了 讨论 过 的 路 由 库 
react-router 和 react-router-redux。 此 外 ， 还 有 Ajax 请 求 兼 容 库 whatwg-fetch。 


5.6.2 ”划分 目录 结构 
安装 完 依赖 后 ， 我 们 的 目录 结构 是 这 样 的 : 



































上 一 node_ modules 
[一 package.json 


一 般 来 说 ,我 们 希望 把 所 有 的 源 文件 放 在 src/ 目录 下 ， 把 测试 文件 放 在 test/ 目录 下 ， 而 最 终 
生成 的 、 供 HTML 引用 的 文件 放 在 build/ 目录 下 : 


$ mkdir src 
$ mkdir test 
$ mkdir build 


接 下 来 的 初始 化 工作 会 比较 头疼 ， 那 就 是 src/ 目录 下 的 源 代码 该 怎样 组 织 。 


在 大 部 分 的 Redux 应 用 例子 中 ， 我 们 都 使 用 了 根据 类 型 划分 的 文件 结构 ( file structure based 
type )， 其 形式 大 致 如 下 : 


STC/ 

| 一 appjs 
actions 
上 一 XXAction.js 
[一 YYAction.js 
componets 
| 一 XXComponent.js 


| 

一 

| -一 YYComponentjs 
-一 

| 

| 














constants 

上 一 XXConstants.js 

-一 YYConstants,js 
[一 reducers 

上 一 XXReducer.js 

-一 YYReducerjs 


在 一 些 功 能 简单 的 Redux 应 用 中 , 推荐 这 样 划 分 。 然而 在 大 型 应 用 中 , 一 般 会 存在 多 个 页 面 ， 
每 个 页 面 下 的 components 、actions 和 reducers 都 少 有 交集 ， 这 时 如 果 还 是 简单 的 根据 类 型 划分 文 














ea 
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件 结构 ， 就 会 导致 单个 文件 夹 下 文件 过 多 ， 在 开发 中 难以 快速 定位 某 个 文件 。 


因此 , 在 多 个 Redux 项 目 实践 的 基础 上 , 我 们 将 在 示例 博客 项 目 中 使 用 混合 方式 划分 文件 结 
构 ， 既 采用 了 类 型 划分 的 优势 ， 又 添加 了 功能 划分 (file structure based feature ) 的 特点 。 


HomeRedux.js 


Table.js 
一 Table.css 
-一 TableRedux.js 
-一 shared 
上 一 containers 
| -一 DevTools.js 
Rootjs 
layouts 
redux 
| [一 reducersjs 
上 -一 Toutes 
| 一 utils 


一 styles 
app.css 


基本 上 ， 我们 只 


| 
| 
| 一 components 
| 
| 
| 
| 


组 件 一 致 。 


需要 关注 的 就 是 views/ 和 components/ 这 两 个 文件 夹 ， 它 们 也 是 存放 绝 大 多 5 
数 业 务 代码 的 地 方 。 这 里 的 两 个 文件 夹 也 正好 与 上 一 节 提 到 的 Views 与 Components 两 个 类 型 的 


所 有 源 代码 存放 的 路 径 

整个 应 用 的 入 口 

应 用 中 某 个 页 面 的 入 口 文件 ， 一 般 为 路 由 组 件 

例如 ， 首 页 的 入 口 就 是 Home.js 

Home 页 面 对 应 的 样式 

Home 页 面 中 所 有 与 Redux 相关 的 reducer、action creator 的 汇总 ， 即 components/ 
Home/ 下 所 有 *Redux.js 的 汇总 

所 有 应 用 的 组 件 

例如 ，vViews/ 中 一 个 名 为 Home 的 View， 则 在 components/ 中 就 有 一 个 名 为 Home 
的 子 文 件 夹 

Home 页 面 中 的 一 个 列表 组 件 

列表 组 件 对 应 的 样式 

列表 组 件 的 reducer、action creator 及 action type， 整 合 在 同一 个 文件 中 

不 归属 于 任何 View 的 组 件 ， 如 一 些 公共 组 件 等 


配置 DevTools 

一 般 被 app.js 依赖 ， 用 于 根据 环境 判断 是 否 需 要 加 载 DevTools 
布局 相关 的 组 件 及 样式 ， 如 菜单 、 侧 边栏 、header、footer 等 
Redux store 相关 的 配置 

整个 应 用 中 所 有 reducer 的 汇总 

路 由 相关 的 配置 

工具 函数 、 常 量 等 

全 局 公共 样式 

应 用 主 样 式 表 




















在 views/ 文 件 夹 中 ,存放 的 是 每 个 路 由 的 人口 页 ， 如 首页 (Home )、 详 情 页 (Detail )、 管 理 



































后 台 页 (Admin ) 等 。 而 每 一 个 人 口 都 会 有 三 个 文件 : *.js 是 入 口 的 组 件 ，*.css 是 对 应 组 件 的 样 


式 ， 而 *Redux.js 是 components/Home/ 文件 夹 下 所 有 reducer 和 action 的 聚合 。 
在 components/Home/ 文件 夹 里 ， 是 当前 路 由 对 应 的 页 面 (Home ) 需要 的 所 有 内 容 一 一 


MA 
components 、actions 、reducers、 样 式 等 。 

















说 明 什么 是 *Reduxjs? 实际 上 ， 按 照 Redux 应 用 的 一 般 目录 结构 划分 方式 ， 应 该 分 别 有 
reducers 、action creators 和 constants 文件 夹 。 但 是 在 实际 应 用 中 ,我 们 发 现 这 样 的 划分 方式 
略 显 烦琐 ， 添 加 一 个 组 件 需要 至 少 新 建 4 个 文件 。 同 时 对 于 业务 应 用 来 说 ，reducers 等 于 
Redux 相关 的 文件 并 不 太 可 能 被 其 他 地 方 复 用 ， 因 此 放 在 一 个 文件 里 组 织 并 管理 是 更 好 的 
选择 。 目 前 ， 在 Redux 社区 中 也 存在 一 个 类 似 的 规范 "。 





Q@ Ducks modular redux， 详 见 https://github.com/erikras/ducks-modular-redux。 
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5.6.3 设计 路 由 


在 开始 具体 写 代 码 之 前 ， 我 们 还 需要 做 另外 一 项 非常 重要 的 规划 一 一 设计 路 由 。 
以 我 们 的 博客 系统 为 例 ， 起 码 需 要 一 个 首页 来 显示 文章 列表 ， 一 个 详情 页 来 显示 博客 内 容 ， 





一 个 后 台 管 理 页 来 方便 我 们 对 文章 数据 进行 增 、 删 、 改 、 查 。 





因此 ， 我 们 分 别 在 src/views/ 和 src/components/ 下 新 建 对 应 的 文件 夹 和 文件 : 


src/ 
上 一 components 
| 上 一 Detail 文章 详情 页 
| [一 Home 文章 列表 页 
LViews 

|— Detail.css 

| 一 Detail.js 

| 一 DetailRedux.js 

上- 一 Home.css 

上 -一 Home.js 


LL HomeRedux.js 


按照 我 们 的 目录 结构 ， 所 有 的 路 由 配置 应 该 放 在 src/routes/ 目录 下 
index.js 文件 ， 用 来 配置 整个 应 用 的 所 有 路 由 信息 : 








STC/ 

上 一 components 
Toutes 

| Lindex.js 

LViews 


在 路 由 配置 文件 中 ， 首 先 应 该 引入 所 有 需要 的 依赖 : 


// routes/index.js 
import React from 'react'; 
import { Router, Route, IndexRoute, hashHistory } from 'react-router'; 




















import Home from '../views/Home'; 
import Detail from '../views/Detail'; 


接 下 来 ， 使 用 react-router 提供 的 组 件 来 定义 应 用 的 路 由 : 


Const routes = ( 
<Router history={hashHistory}> 
<Route path="/" component={Home} /> 
<Route path="/detail/:id" component={Detail} /> 
</Router> 


)3 


， 因 此 在 这 个 目录 下 新 建 


在 上 述 配置 里 ， 我 们 先 告 诉 react-router 使 用 hashHistory 作为 前 端 路 由 的 实现 方式 ， 通 过 改 


变 URL 的 散 列 值 (# 后 面 的 部 分 ) 来 实现 路 由 的 切换 。 使 用 hashHistory 的 好 处 是 实现 简单 ， 


容 性 好 ， 不 需要 做 额外 的 服务 端 改 造 。 





兼 
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如 果 追 求 更 好 的 用 户 体验 ， 使 用 browserHistory 是 更 好 的 选择 。browserHistory 使 用 的 是 
HTMLS 的 pushstate API。 这 种 技术 也 有 一 定 的 局 限 性 ， 首 先 需要 服务 器 端 将 所 有 的 请 求 重 定向 
到 首页 ， 其 次 部 分 较 老 的 浏览 器 并 不 支持 pushstate 技术 。 

为 了 得 到 更 好 的 兼容 性 ， 我 们 在 实例 项 目 中 选择 hashHistory。 

接 下 来 是 我 们 熟悉 的 标签 筷 套 语 法 ,在 <Router> 标签 内 部 ， 是 两 个 <Route> 标签 ， 它 们 代表 
着 我 们 定义 的 两 条 路 由 记录 ， 对 应 的 目录 如 下 : 














/ 首页 ， 即 文章 列表 页 
/detail/:id 文章 详情 页 





每 条 路 由 信息 都 包含 了 对 应 的 路 径 和 需要 泻 染 的 组 件 。 可 以 看 到 ， 这 些 组 件 就 是 我 们 在 
views/ 文件 夹 中 定义 的 路 由 入 口 页 组 件 。 


最 后 ， 为 了 能 最 快 看 到 效果 ， 我 们 将 views/ 下 的 所 有 路 由 入 口 组 件 初始 化 为 只 泻 染 标题 的 
React 组 件 。 以 Home 组 件 为 例 ，src/views/Home.js 文件 中 的 代码 如 下 : 


























import React, { Component } from 'react'; 


class Home extends Component { 
render() { 
return ( 
<h1>Home</h1> 
); 
} 
3 


export default Home; 5 


Detail.js 同 理 ， 这 里 不 再 详 述 。 





5.6.4 让 应 用 跑 起 来 


现在 我 们 已 经 配置 好 了 整个 应 用 的 路 由 , 那么 该 怎么 在 浏览 器 中 看 到 效果 呢 ? 很 显然 , 我 们 
需要 一 个 应 用 的 入 口 文件 ， 通 常会 将 其 命名 为 appjs。 


让 我 们 在 src/ 文件 夹 下 新 建 app.js: 


src/ 
上 一 appjs 
上 一 components 


上 一 Toutes 


[一 views 











然后 在 文件 的 开头 引入 需要 的 依赖 。 很 显然 ， 我 们 需要 React 来 浑 染 所 有 的 组 件 。 此 外 ， 还 
需要 引入 刚刚 定义 的 路 由 结构 : 

















import ReactDOM from 'react-dom'; 
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import routes from './routes/'; 


最 后 ， 只 需要 简单 地 把 路 由 泻 染 到 DOM 环境 中 即 可 。 注 意 ， 这 里 我 们 并 没有 直接 泻 染 到 























document.body 节点 上 ， 而 是 特别 选择 了 id 为 root 的 节点 : 





ReactDOM. render(routes, document.getElementById('root')); 


React 官方 并 不 推荐 将 组 件 泻 染 到 document.body 上 ， 因 为 这 个 节点 很 可 能 会 被 修改 ， 比 如 








动态 添加 一 个 <script> 标签 等 ， 这 将 使 React 的 DOM diff 计算 变 得 更 加 困难 。 


到 这 里 , 整个 App 的 秩 形 已 经 完成 了 , 但 它 只 有 最 基本 的 路 由 功能 。 那么 该 怎么 在 浏览 需 里 


看 到 效果 呢 ? 没 错 ， 我 们 还 需要 一 个 HTML 页 面 。 





在 根 目 录 下 再 新 建 一 个 index.html 用 于 加 载 所 有 的 脚本 和 样式 文件 : 


<!DOCTYPE htmL> 
<html> 
<head> 
<title>redux blog</title> 
</head> 
<body> 
<div id="root"></div> 
<script type="text/javascript" src="build/app.bundle.js"></script> 
</body> 
</html> 


看 了 上 述 代码 ， 你 肯定 会 疑惑 ， 为 什么 加 载 JavaScript 脚本 的 地 址 是 build/app.bundle.js? 这 





就 涉及 我 们 在 附录 A 中 提 到 的 构建 工具 webpack 了 , 它 会 把 src/ 目录 下 的 所 有 文件 根据 依赖 关系 
打包 成 一 个 可 供 浏览 器 加 载 并 执行 的 JavaScript 文件 。 

















这 是 构建 相关 的 配置 。 在 附录 A 中 ， 我们 会 学 到 如 何 搭建 基本 的 React 项 目 环境 ,包括 使 用 











nvm 管理 Node.js 版 本 、 使 用 Babel 将 ES6 语 法 编译 为 兼容 性 更 好 的 ES5 代码 、 使 用 Sass 来 编写 
和 管理 样式 等 。 





























但 是 对 于 一 个 完整 的 前 端 应 用 来 说 ,这 些 准 备 工作 还 远 远 不 够 。 在 Redux SPA 项 目 中 , 我 们 








依然 使 用 webpack 构建 。 可 以 说 ，webpack 已 经 成 为 React 社区 中 的 御用 工具 。 在 本 节 后 面 我 们 
会 提 到 ， Redux 作者 开发 的 react-transform-hmr 和 react-transform-catch-errors 等 都 可 以 方便 地 整 


合 进 webpack 的 构建 脚本 中 使 用 。 














配置 webpack 来 实现 SPA 的 构建 、 自 动 刷 新 其 至 组 件 热 重 载 以 及 ES6 语 法 转译 ,与 配置 React 











应 用 大 同 小 异 ， 具 体 可 参见 附录 A。 现 在 让 我 们 在 整个 应 用 的 根 目 录 下 新 建 webpack.config.js 来 





配置 构建 工具 webpack: 


var path = require('path'); 


module.exports = { 
entry: 'src/app.js', 
output: { 
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path: path.join(__dirname, 'build'), 
filename: 'app.bundle.js', 
publicpath: '/build/', 


}, 
module: { 
loaders: [{ 
test: /\.js$/, 
include: path.join(__dirname, 'src'), 
loader: 'babel', 
}]， 
}， 
}; 


简单 地 说 ， 这 个 配置 文件 让 webpack 以 src/app.js 为 入 口 ， 将 文件 需要 的 所 有 依赖 打包 成 一 
个 独立 可 执行 的 JavaScript 文件 ， 并 保存 到 build/app.bundle.js。 此 外 ， 当 解析 src/ 文件 夹 下 的 js 
文件 时 ,使 用 Babel 进行 转译 。 

我 们 需要 一 段 命令 来 让 webpack 执行 构建 命令 。 因 为 在 后 续 的 教程 中 会 经 常 使 用 这 上 段 命 令 ， 
所 以 我 们 可 以 将 其 写成 npm scripts。 打 开 package.json， 添 加 scripts 字段 : 

{ 

"scripts": { 
"build": "./node_ modules/.bin/webpack" 


} 
} 


后 面 就 可 以 通过 在 终端 运行 npm run build 命令 来 执行 我 们 的 构建 脚本 了 : 


























$ npm run build 


> redux-blog@1.0.0 build /Code/redux-blog 
> webpack 


Hash: 3b0c35273ffeb406d662 
Version: webpack 1.12.14 
Time: 1331ms 
Asset Size Chunks Chunk Names 
app.bundle.js 833 kB 0 [emitted] main 
+ 220 hidden modules 


一 切 正常 的 话 , 就 会 发 现 build/ 文件 夹 已 经 被 自动 创建 , 里 面 有 一 个 全 新 的 文件 app.bundle.js。 
接着 赶紧 用 浏览 器 打开 index.html 看 看 效果 ， 如 图 5-7 所 示 。 
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DD redux blog 


口 file:///Code/redux-blog/index.html#/?_k=0e9k95 

















图 5-7 Redux 应 用 的 执行 结果 


这 个 Redux 应 用 看 起 来 并 不 是 很 高 大 上 ， 因 为 看 到 的 只 是 一 个 突 雹 的 <h1> 标签 而 已 。 另 外 ， 
我 们 注意 一 下 地 址 栏 ， 当 前 页 面 的 地 址 看 着 也 有 些 奇 怪 : file:///Code/redux-blog/index. 
html#/? k=0e9k95。 


因为 我 们 没有 在 本 地 启动 一 个 静态 文件 服务 右 ， 所 以 浏览 器 用 包 e:/ 协议 解析 了 index.html。 


比较 奇怪 的 是 # 之 后 的 部 分 。 了 解 URL 知识 的 人 应 该 知道 # 之 后 的 部 分 称 为 散 列 (hash )， 
改变 散 列 值 并 不 会 触发 页 面 跳 转 ， 而 是 会 在 页 面 中 跳 转 到 相应 的 锚 点 〈 若 存在 的 话 )。 

而 对 于 我 们 的 应 用 来 说 ， 真 正 的 路 由 信息 其 实 就 存在 于 # 号 之 后 。 实 际 上 ， 你 会 在 # 之 后 看 
到 许多 有 意思 的 符号 ， 比 如 index.html#/detail/3?mode=1#title 是 一 个 非常 典型 的 前 端 路 由 URL。 
对 于 浏览 器 来 说 ， 这 段 URL 的 散 列 值 是 #/detail/3?mode=1#title， 但 是 React Router 又 对 这 段 
散 列 做 了 解析 ， 生 成 了 逻辑 上 的 前 端 路 由 ， 包 含 path、query 和 hash 等 概念 。 

现在 ， 试 试 在 # 之 后 输入 下 面 一 段 URL， 看 看 发 生 了 什么 : 

index.html#/detail 

我 们 发 现 界面 依然 很 丑 , <h1> 标题 依然 很 突 无, 但 是 标题 的 文字 已 经 从 Home 变 成 了 Detail， 
这 就 是 React Router 带 给 我 们 的 前 端 路 由 系统 。 

最 后 还 有 一 点 比较 奇怪 ， 那 段 ?_k=9e9k95 是 什么 ?我们 知道 在 URL 中 ? 之 后 表示 的 是 
query, 这 段 query 事实 上 是 React Router 为 了 提供 每 一 条 路 由 记录 持久 化 数据 而 生成 的 唯一 标识 。 
如 果 你 不 需要 这 样 的 特性 ， 也 可 以 使 用 React Router 提供 的 createHistory 方法 创建 自 定义 的 
history 对 象 。 
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5.6.5 ”优化 构建 脚本 

首先 ， 琢 待 解 决 的 问题 是 应 用 的 URL。 很 显然 ，fie:/W/ 并 不 是 一 个 合适 的 URL 前 级 。 我 们 
知道 ,一 般 网 站 都 会 采用 HTTP 或 HTTPS 协议 来 提供 Web 网 页 ,因此 需要 在 本 地 启动 一 个 http 服 
务 器 以 便 我 们 通过 HTTP 协议 访问 应 用 。 

此 外 ， 虽 然 我 们 把 webpack 的 构建 脚本 集成 到 了 npm scripts 中 ,但 是 每 次 修改 都 需要 在 终 
端 执行 npm run buttLd 命令 也 是 一 种 痛苦 。 如 果 每 次 修改 源 代码 时 都 能 自动 构建 并 刷新 页 面 ， 那 
将 是 一 种 非常 好 的 开发 体验 。 好 消息 是 ， 这 些 都 可 以 通过 webpack-dev-server 简单 实现 。 

首先 ， 添 加 webpack-dev-server 作为 项 目的 依赖 : 

























































































$ npm install -D webpack-dev-server 
接 下 来 ， 将 下 面 的 脚本 添加 到 npm scripts 中 ， 我 们 后 续 将 用 npm run watch 命令 来 执行 : 
./node_moduLes/ .bin/webpack-dev-server --hot --inline --content-base . 


在 终端 中 运行 npm runstart， 将 会 看 到 webpack 输出 一 长 串 的 构建 信息 。 这 时 打开 浏览 器 ， 
输入 http://localhost:8080/, 看 看 是 不 是 和 原来 直接 用 浏览 器 打开 index.html 看 到 的 效果 一 模 一 样 ? 


























说 明 如果 没有 正常 看 到 页 面 ， 该 怎么 办 ? 确认 本 地 的 8080 端口 是 否 被 占用 ,若是 ， 则 可 以 给 
webpack-dev-server 添加 --port 7777 参数 来 指定 自 定义 的 端口 。 


5.6.6 添加 布局 文件 

虽然 我 们 已 经 在 浏览 占 中 看 到 了 整个 应 用 的 雏形 , 但 总 觉得 哪里 还 是 不 对 劲 。 一 般 来 说 , 一 
个 网 站 起 码 会 有 一 个 导航 栏 ， 用 于 提供 各 种 链接 ， 而 不 是 让 用 户 手动 输入 URL 来 实现 页 面 的 切 
换 。 此 外 ， 可 能 还 会 有 一 个 公共 的 页 脚 ， 用 于 显示 版 权 信息 、 友 情 链 接 或 者 备案 信息 等 。 

那么 ， 这些 文 件 应 该 怎么 组 织 呢 ? 显然 ,它们 应 该 被 放置 在 布局 文件 所 在 的 src/layouts 文件 
夹 下 。 下 面 让 我 们 来 创建 这 些 文件 。 



































说 明 为 了 在 浏览 器 中 看 到 每 次 代码 变动 后 的 效果 ， 我 们 需要 不 断 执行 npm run butLd 命令 。 实 际 
上 , 可 以 启动 Webpack 的 watch 模式 , 每 当 文件 发 生 改 交 时 ,自动 重新 构建 。 在 package.json 
的 scripts 中 添加 一 条 新 的 记录 可 以 解决 这 个 问题 : "watch":"./node_modules/.bin/webpack 
--watch"。 然 后 在 终端 中 执行 npm run watch 命令 。 





首先 ， 新 建 src/layouts 目录 ， 然 后 添加 两 个 文件 一 一 Frame.js 和 Nav.js: 





A 
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src/ 

-一 components 
-一 layouts 

| 上 一 Frame.js 
| Navjs 


CC routes 


[一 views 


接着 我 们 先 看 看 Navjs。 顾 名 思 义 ， 这 个 组 件 里 将 会 显示 所 有 的 导航 链接 。 实 际 上 ， 它 的 代 
码 也 很 简单 : 














import React, { Component } from 'react'; 
import { Link } from 'react-router'; 


class Nav extends Component { 
render() { 
return ( 
<nav> 
<Link to="/">Home</Link> 
</nav> 
); 
} 
} 





唯一 需要 注意 的 是 ， 我 们 引入 了 React Router 提供 的 Link 组 件 ， 使 用 这 个 组 件 可 以 模拟 <a> 
标签 进行 链接 跳 转 。<Link> 的 使 用 方法 与 <a> 非常 类 似 , 唯一 不 同 的 是 在 指定 链接 的 时 候 使 用 to 
属性 而 不 是 href。 


























接 下 来 ,我 们 还 引入 了 一 个 新 的 组 件 Frame.js。 先 看 看 它 长 什么 样 : 


import React, { Component } from 'react'; 
import Nav from './Nav'; 


class Frame extends Component { 
render() { 
return ( 
<div className="frame"> 
<section className="header"> 
<Nav /> 
</section> 
<section className="container"> 
{this.props.children} 
</section> 
</div> 
); 
} 
} 


可 以 看 到 ，Frame 引入 了 Nav 组 件 作为 依赖 ， 并 将 其 泻 染 了 出 来 。 此 外 ，Frame 组 件 还 泻 染 
T this.props.children。 


旦 本 
让 我 们 再 思考 






































下 我 们 的 页 面 一 一 文章 列表 页 和 详情 页 ， 每 一 个 页 面 的 结构 都 是 导航 + 具体 
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模块 的 结构 。 当 然 ， 我 们 也 可 以 在 每 个 组 件 的 render 方法 里 写 人 路 由 ,但 是 这 样 明显 会 造成 代 
码 的 匈 余 ， 也 没有 实现 模块 之 间 的 关注 分 离 。 

所 以 ， 我 们 抽出 了 Frame 组 件 来 实现 这 样 的 结构 。 实 际 上 ， 这 也 是 layouts/ 文件 夹 下 的 组 件 
需要 实现 的 功能 。 

那么 ,在 Frame 组 件 中 this.props.children 代表 什么 呢 ? 在 解释 之 前 ， 我 们 需要 对 
src/routes/index.js 进行 一 番 改 造 : 





import React from 'react'; 
import { Router, Route, IndexRoute, hashHistory } from "react-router ' ; 


import Frame from '../Llayouts/Frame'; 
import Home from '../views/Home'; 
import Detail from '../views/Detail'; 


const routes = ( 
<Router history={hashHistory}> 
<Route path="/" component={Frame}> 
<IndexRoute component={Home} /> 
<Route path="/detail/:id" component={Detail} /> 
</Route> 
</Router> 


); 

export default routes; 

首先 ， 我们 引入 了 React Router 提供 的 另外 一 个 组 件 IndexRoute， 同 时 引入 了 刚刚 添加 的 
layouts 目录 下 的 Frame 组 件 。 

我 们 做 出 的 最 大 改变 是 ， 原 本 并 列 式 的 路 由 声明 变 成 了 般 套 式 的 路 由 声明 。 最 外 层 的 
<Router> 配置 没有 变化 ，/ 路 由 对 应 的 组 件 不 再 是 Home， 而 变 成 了 Frame。 也 就 是 说 ， 当 访问 / 
路 由 时 ， 将 泻 染 Frame 组 件 。 

但 是 ，Frame 组 件 除 了 泻 染 导航 之 外 ， 并 没有 演 染 任何 有 意义 的 东西 啊 ? 是 的 ， 这 就 是 为 什 
么 我 们 能 套 了 一 个 <IndexRoute> 组 件 。 这 样 的 定义 表示 当 访 问 / 时, 实际 泻 染 的 组 件 是 Frame 和 
Home。 

在 这 种 情况 下 ， Home 组 件 就 会 作为 Frame 组 件 的 子 组 件 。 因 此 , 在 Frame 的 render 方法 
中 泻 染 this.props.chiLdren 时 ， 泻 染 的 其 实 是 Home 组 件 。 

另外 一 条 路 由 /detail/:id 也 被 定义 成 了 / 的 子路 由 ， 这 意味 着 当 访 问 /detail 时 ， 泻 染 的 
是 Frame 和 Detail 组件。 

做 好 了 这 些 修改 ， 打 开 浏 览 器 再 来 看 看 效果 ， 如 图 5-8 所 示 。 
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四 ) redux blog 


所 © 口 127.0.0.1:8080/#/?_k=z1bqnz 





Home 


Home 








图 5-8 导航 效果 


5.6.7 ”准备 首页 的 数据 





当 访 问 我 们 的 博客 时 , 用 户 希 望 看 到 的 自然 是 文章 列表 , 这 也 是 Home 组 件 需 要 显示 的 数据 。 


在 5.6.2 节 中 我 们 说 到 ，views/ 文件 夹 下 放 着 的 是 所 有 的 路 由 入 口 页 ， 而 components/ 下 放 着 
的 是 每 个 人 口 页 需要 的 组 件 、 样 式 以 及 Redux 相关 的 文件 。 


因此 ， 我 们 需要 在 srclcomponents/Home/ 文件 夹 下 添加 几 个 新 文件 : 








SITC/ 

上 一 components 

| 上 一 Detail 

| LHome 

| HF Preview.css 

| 广 一 Preview.js 

| Co PreviewList.js 

| LL previewListRedux.js 
CC layouts 

上 一 Toutes 


[一 views 


其 中 Previewjs 中 定义 了 一 个 纯 泻 染 、 无 状态 的 文章 预览 组 件 : 


import React, { Component } from 'react'; 
import './Preview.css'; 


class Preview extends Component { 
static propTypes = { 

title: React.PropTypes.string， 

Link: React.PropTypes.string， 
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}; 
render() { 
return ( 
<article className="article-preview-item"> 
<h1 className="title">{this.props.title}</hi> 
<span className="date">{this.props.date}</span> 
<p className="desc">{this.props.description}</p> 
</article> 
); 
} 


} 

















我 们 在 这 个 组 件 中 引入 了 一 个 名 为 Preview.css 样式 文件 。 顾名思义 ， 这 是 Preview 组 件 依 赖 
的 样式 文件 。 但 JavaScript 中 怎么 能 引入 CSS 呢 ?” 实 际 上 ， 其 实 这 是 webpack 的 一 个 插件 


css-loader 所 做 的 。css-loader 会 识别 到 所 有 引入 CSS 的 语句 ， 并 解析 出 对 应 的 CSS 文件 地 址 ， 以 
<style> 标签 的 形式 动态 插入 到 DOM 节点 中 。 








接 下 来 的 内 容 会 稍 显 复 杂 。 首 先 看 看 PreviewList.js: 


import React, { Component } from 'react'; 
import Preview from './Preview'; 


class PreviewList extends Component { 
static propTypes = { 


articleList: React.PropTypes.arrayOf(React.PropTypes.object) 
}; 


render() { 
return this.props.articlelist.map(item => ( 

<Preview {...item} key={itenm.id} /> 
)); 


} 
} 




















可 以 看 出 ,PreviewList 也 是 一 个 无 状态 组 件 , 它 引入 了 Preview 组 件 ,并 将 传人 的 articleList 
遍历 泻 染 出 若干 个 对 应 的 Preview 组 件 。 

PreviewList 本 身 并 没有 什么 特别 难以 理解 的 地 方 ， 但 是 和 它 名 字 很 相似 的 PreviewList- 
Redux.js 则 是 本 节 内 容 的 关键 。 在 介绍 Redux 应 用 目录 结构 时 , 我们 提 到 过 ，*Redux.js 里 包含 了 


*#.js 这 个 组 件 需要 的 reducer 、action creator 和 constants。 


现在 让 我 们 揭 开 它们 的 神秘 面纱 : 


























const initialState = { 
loading: true, 
error: false, 
articleList: []， 


}; 


const LOAD_ARTICLES = 'LOAD_ARTICLES'; 


244 第 5 章 深入 Redux 应 用 架构 





const LOAD_ARTICLES_SUCCESS = "LOAD_ARTICLES_SUCCESS ' ; 
const LOAD_ARTICLES_ERROR = "LOAD_ARTICLES_ERROR ' ; 


export function loadArticles() { 
return { 
types: [LOAD ARTICLES, LOAD ARTICLES_SUCCESS, LOAD_ARTICLES_ERROR], 
url: '/api/articles.json', 
}; 
} 


function previewList(state = initialState, action) { 
switch (action.type) { 
case LOAD ARTICLES: { 
return { 
...State, 
loading: true, 
error: false, 
}; 
} 


case LOAD ARTICLES_SUCCESS: { 
return { 
...State, 
loading: false, 
error: false, 
articleList: action.payload.articleList, 
}; 
} 


case LOAD_ARTICLES_ERROR: { 
return { 
...State, 
loading: false, 
error: true, 
}; 
} 


default: 
return state; 


} 
} 


export default previewList; 

这 是 实例 中 截至 目前 为 止 最 复杂 的 文件 ， 下 面 让 我 们 分 3 部 分 来 理解 它 。 

首先 ， 它 定义 了 initialstate。 可 以 看 到 ， 它 在 文件 末尾 的 previewList 函数 ( 目前 我 们 暂 
且 叫 它 函 数 ) 中 作为 第 一 个 参数 state 的 默认 值 。 也 就 是 说 ， 当 传人 的 state 为 空 时 ，state 将 使 
用 initialstate 的 值 。 

定义 initialstate 是 为 了 Redux 初始 化 并 确定 每 个 reducer 的 结构 。 而 当初 始 化 完成 后 ， 每 
次 响应 action 时 ，reducer 将 获得 上 一 次 计算 出 的 state 作为 参数 ， 这 时 initialstate 将 不 再 发 挥 
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作用 。 

接 下 来 的 3 个 常量 定义 和 一 个 函数 定义 在 逻辑 上 属于 一 个 整体 ， 但 是 分 别 有 不 同 的 意义 。 
LOAD_ARTICLES 等 3 个 常量 就 是 我 们 说 的 constants， 也 就 是 一 个 action 中 的 type 字段 ， 它 们 用 
来 标识 Redux 应 用 中 一 个 独立 的 action。 

而 LoadArticles() 就 是 一 个 action creator。 因 为 每 次 调用 LoadArticles() 函数 时 ， 它 都 会 返 
回 一 个 action， 所 以 action creator 之 名 恰如其分 。 

至 于 这 个 action creator 返回 的 action, 我 们 已 经 在 $.2 节 里 提 到 过 , 它 是 由 redux-composable- 
fetch 这 个 middleware 所 定义 的 格式 。 

在 PreviewListRedux.js 的 最 后 ， 则 是 我 们 定义 的 reducer。 可 以 看 到 ， 我 们 的 reducer 会 响应 
3 种 类 型 的 action: LOAD_ARTICLES、 LOAD_ARTICLES_SUCCESS 和 LOAD _ARTICLES_ERROR ， 这 也 是 我 
们 在 之 前 刚刚 定义 的 action creator 可 能 会 触发 的 action 类 型 。 

看 到 这 里 ， 我 们 应 该 大 概 明白 了 一 个 *Redux.js 文件 所 包含 的 内 容 与 各 自 的 职责 。 接 下 来 ， 
我 们 继续 看 看 它们 是 怎么 在 整个 Redux 应 用 中 发 挥 作 用 的 。 




























































































5.6.8 连接 Redux 

在 5.6.7 节 中 ， 我 们 终于 见识 了 reducer 和 action creator 的 真面目 ， 而 在 这 一 节 中 ， 我 们 将 学 
习 怎 么 将 这 些 reducer 和 action creator 整合 起 来 ， 最 终 变 成 应 用 中 的 一 部 分 。 

在 5.5 节 中 ,我 们 详解 了 两 类 组 件 一 一 容器 型 组 件 和 展示 型 组 件 ， 这 两 类 组 件 最 直观 的 区 别 在 
于 是 否 感知 Redux 的 存在 ， 或 者 说 ， 是 和 否 使 用 connect 方法 让 组 件 从 Redux 的 状态 树 中 获取 数据 。 

1. 让 容器 型 组 件 关 联 数 据 


我 们 现在 已 经 熟悉 了 views/ 文 件 夹 和 components/ 文 件 夹 的 职责 区 别 。 很 显然 ，views/ 
HomeRedux.js 包含 了 Home 页面 所 有 组 件 相 关 的 reducer 及 actionCreator: 


























import { combineReducers } from "redux '; 


// 引入 reducer 及 actionCreator 
import list from '../components/Home/PreviewListRedux'; 


export default combineReducers({ 
list, 
]); 


export * as listAction from '../components/Home/PreviewListRedux ' ; 


可 以 看 到 ，views/ 目录 下 的 *Redux.js 文件 在 更 大 程度 上 只 是 起 到 一 个 整合 分 发 的 作用 。 和 
components/ 目录 下 的 *Redux.js 文件 一 样 ， 它 默认 导出 的 是 当前 路 由 需要 的 所 有 reducer 的 集合 。 
这 里 我 们 引入 了 Redux 官方 提供 的 combineReducers 方法 ， 通 过 这 个 方法 ， 我 们 可 以 方便 地 将 多 
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个 reducer 合并 为 一 个 。 


此 外 ，HomeRedux.js 还 将 PreviewListRedux.js 中 所 有 导出 的 对 象 合 并 后 ， 导 出 一 个 
ListAction 对 象 。 稍 后 ， 就 会 看 到 我 们 为 什么 要 这 么 组 织 文件 。 


先 对 views/Home.js 做 一 些 修 改 ， 让 它 与 Redux 进行 第 一 次 亲密 接触 : 





import React, { Component } from 'react'; 

import { bindActionCreators } from 'redux'; 

import { connect } from 'react-redux'; 

import PreviewList from '../components/Home/PreviewList'; 
import { listActions } from './HomeRedux'; 


class Home extends Component { 
render() { 
return ( 
<div> 
<h1>Home</h1> 
<PreviewList 
{...this.props.list} 
{...this.props.listActions} 
/> 


</div> 


export default connect(state => { 
return { 
list: state.home.list, 
}; 
}, dispatch => { 
return { 
listActions: bindActionCreators(listActions, dispatch), 
}; 
}) (Home); 





这 里 我 们 引入 了 Redux 提供 的 工具 方法 bindActionCreators、 react-redux 提供 的 connect 方 
法 以 及 在 components/Home/ 下 的 PreviewList 组 件 。 


另 一 个 值得 关注 的 修改 点 是 ， 我 们 不 再 默认 导出 一 个 React 组 件 ， 而 是 导出 了 将 Home 组 件 
传人 connect 函数 调用 的 结果 后 最 终生 成 的 组 件 。 


事实 上 ,调用 connect 函数 返回 了 一 个 高 阶 组 件 生成 器 ， 而 这 个 生成 需 会 基于 原始 组 件 生成 
一 个 全 新 的 组 件 ， 并 给 这 个 组 件 添 加 额外 的 props。 


在 构造 一 个 高 阶 组 件 生成 器 时 ，connect 最 多 接受 4 个 参数 ， 分 别 如 下 。 




















口 [mapStateToProps(state, [ownProps]): stateProps] ( 类 型 : 函数 ) : 接受 完整 的 Redux 
状态 树 作 为 参数 ， 返 回 当前 组 件 相关 部 分 的 状态 树 ， 返 回 对 象 的 所 有 key 都 会 成 为 组 件 
的 props。 
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口 [mapDispatchToProps(dispatch，[ownProps]): dispatchProps] ( 类 型 : 对 象 或 函数 ) : 
接受 Redux 的 dispatch 方法 作为 参数 ， 返 回 当前 组 件 相关 部 分 的 action creator， 并 可 以 
在 这 里 将 action creator 与 dispatch 绑 定 ， 减 少见 余 代码 。 
口 [mergeProps(stateProps, dispatchProps, ownProps): props] ( 类 型 : 函数 ) : 如 果 指 定 
这 个 函数 ， 你 将 分 别 获 得 mapStateToProps 、mapDispatchToProps 返回 值 以 及 当前 组 件 的 
props 作为 参数 ， 最 终 返 回 你 期 望 的 、 完 整 的 props。 
口 [options] ( 类 型 : 对 象 ) : 可 选 的 额外 配置 项 ， 有 以 下 两 项 。 
@ [pure = true] ( 类 型 :布尔 ); 该 值 设 为 true 时 ,将 为 组 件 添加 shouldComponentUpdate() 
生命 周期 函数 ， 并 对 mergeProps 方法 返回 的 props 进行 浅 层 对 比 。 
ms [withRef = false] ( 类 型 : 布尔 ) : 车 设 为 true， 则 为 组 件 添加 一 个 ref 值 ， 后 续 可 
以 使 用 getwrappedInstance() 方法 来 获取 该 ref， 默 认为 false。 
关于 connect 函数 的 更 多 用 法 及 背后 的 原理 ， 请 参考 6.5 节 。 
在 我 们 的 例子 中 ， 我 们 暂时 只 关心 前 两 个 参数 ， 即 mapStateToProps 和 mapDispatchToProps。 
在 mapStateToProps 中 ， 我 们 从 整 棵 Redux 状态 树 中 选取 了 state.home.list 分 支 作为 当前 
组 件 的 props， 并 将 其 命名 为 list。 这 样 ， 在 Home 组 件 中 ， 就 可 以 使 用 this.props.tist 来 获取 
到 所 有 PreviewListRedux 中 定义 的 状态 。 
而 在 mapDispatchToProps 中 ， 我 们 从 前 面 提 到 的 HomeRedux.js 中 引入 了 listActions， 并 使 
用 Redux 提供 的 工具 函数 将 ListActions 中 的 每 一 个 action creator ( 目前 只 有 一 个 ) 与 dispatch 进 
行 绑 定 ， 最 终 我 们 可 以 在 Home 组 件 中 使 用 this.props.listActions 来 获取 到 绑 定 之 后 的 action 
Creator。 
最 后 , 需要 特别 说 明 的 是 Home 组 件 的 render 方法 。 我 们 将 在 connect 中 对 生成 的 this.props. 
list 和 this.props.listActions 分 别 进行 解构 ， 然 后 传 给 PreviewList 组 件 作 为 props。 
2. 让 展示 型 组 件 使 用 数据 
相 比 于 容器 型 组 件 与 Redux 的 复杂 交互 ， 展 示 型 组 件 实现 起 来 则 简单 得 多 , 毕竟 一 切 需 要 的 
东西 都 已 经 通过 props 传 进 来 了 : 


















































import React, { PropTypes，Component } from 'react'; 
import Preview from './Preview'; 


class PreviewList extends Component { 
static propTypes = { 
loading: PropTypes.bool, 
error: PropTypes.bool, 
articLeList: PropTypes.arrayOf(PropTypes.object), 
loadArticles: PropTypes.func， 
}; 


componentDidMount() { 
this.props.loadArticles(); 
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} 


render() { 
const { loading, error, articlelList } = this.props; 


if (error) { 
return <p className="message">00ops, something is wrong.</p>; 


} 


if (loading) { 
return <p className="message">Loading...</p>; 


} 


return articLeList.map(item => (<Preview {...item} key={item.id} />)); 
} 
} 


首先 , 我 们 扩充 了 原本 定义 的 propTypes, 新 增 了 loading、error 以 及 LoadArtictes 的 定义 。 


其 次 ， 我 们 添加 了 componentDidMount 生命 周期 方法 。 在 PreviewList 组 件 加 载 完成 后 ， 我 们 
调用 了 this.props.loadArticles() 来 加 载 文章 列表 。 


最 后 ， 我 们 在 render 方法 中 针对 不 同 的 状态 浑 染 出 了 友好 的 提示 信息 。 


注意 ， 在 PreviewList 组 件 中 ， 所 有 的 数据 都 来 自 this.props。 展 示 型 组 件 自身 不 维护 任何 
状态 ， 也 不 知道 Redux 的 存在 。 


3. 注入 Redux 


在 “让 容器 型 组 件 关联 数据 ”一 节 中 ， 我 们 学 习 了 如 何 使 用 connect 方法 关联 Redux 状态 
树 中 的 部 分 状态 。 问 题 是 ， 完 整 的 Redux 状态 树 是 哪里 来 的 呢 ? 这 一 节 将 解答 你 的 疑惑 。 


按照 我 们 的 目录 约定 ， 所 有 与 Redux 自身 配置 相关 的 代码 都 放 在 src/redux/ 文件 夹 下 ， 下 面 
让 我 们 来 初始 化 这 些 文件 ; 


STC/ 


| 一 appjs 
components 

一 layouts 

上 一 redux 


| 上 一 configureStore.js 
| Lreducers.js 


一 routes 

[一 views 

先 来 看 看 reducers.js, 这 个 文件 里 汇总 了 整个 应 用 所 有 的 reducer, 而 汇总 的 方法 则 十 分 简单 。 
为 我 们 在 views/ 文件 夹 中 已 经 对 各 个 路 由 需要 的 reducer 做 过 一 次 整理 聚合 , 所 以 在 reducers.js 
中 直接 引用 views/*Redux.js 中 默认 导出 的 reducer 即 可 。 


而 configureStore.js 则 是 生成 Redux store 的 关键 文件 ， 其 中 将 看 到 5.1 节 中 提 到 的 Redux 的 
核心 API- 一 createStore 方法 : 

















划 
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import { createStore, combineReducers, compose, applyMiddleware } from 'redux'; 
import { routerReducer } from 'react-router-redux'; 


import ThunkMiddleware from 'redux-thunk'; 
import rootReducer from './reducers'; 


const finaLCreateStore = Compose( 
applyMiddleware(ThunkMiddleware) 
)(createStore); 


const reducer = combineReducers(Object.assign({}, rootReducer, { 
routing: routerReducer, 


})); 


export default function configureStore(initialState) { 
const store = finalCreateStore(reducer, initialState); 


return store; 


} 


在 configureStore.js 中 ， 并 没有 直接 使 用 Redux 提供 的 原始 createStore 方法 来 创建 store， 
而 是 利用 compose 方法 对 createStore 方法 进行 了 增强 ， 并 生成 了 新 的 createStore 方法 一 一 


finalCreateStore。 


applyMiddleware 是 Redux 提供 的 男 一 个 API， 也 是 Redux 具有 高 度 可 扩展 性 的 重要 保障 。 
使 用 middleware， 可 以 让 Redux 解析 各 种 类 型 的 action。 除 了 最 原始 的 对 象 外 ， 我 们 的 action 还 
可 以 是 方法 、promise， 以 及 任何 你 能 想象 的 类 型 。 


此 外 ,我 们 还 在 初始 化 Store 时 引入 了 react-router-redux 提供 的 routerReducer, 这 个 reducer 帮 
助 我 们 实现 了 路 由 状态 与 Redux store 的 统一 。 


在 完成 store 的 配置 后 ， 我 们 需要 在 某 个 地 方 新 建 一 个 实例 ， 即 app.js: 


import ReactDOM from 'react-dom'; 

import React from 'react'; 

import configureStore from './redux/configureStore'; 
import { Provider } from 'react-redux'; 

import { syncHistoryWithStore } from 'react-router-redux'; 
import { hashHistory } from 'react-router'; 

import routes from './routes'; 
































const store = configureStore(); 
const history = syncHistoryWithStore(hashHistory, store); 


ReactDOM.render(( 
<Provider store={store}> 
{routes(history)} 
</Provider> 
)，document .getELementById('root ' )); 


首先 ， 我 们 引入 了 刚刚 定义 的 configureSstore 方法 。 接 着 ， 引 入 Redux 提供 的 Provider 组 
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件 ， 它 将 成 为 整个 Redux 应 用 的 根 组 件 。 


接 下 来 的 两 个 依赖 是 为 了 完善 我 们 的 路 由 系统 。 我 们 将 原本 在 src/routes/index.js 中 引入 的 
React Router 中 的 hashHistory 改 为 在 app.js 中 引入 ,因为 react-router-redux 需要 对 这 个 history 对 
象 进行 强化 ， 以 此 保证 React Router 与 Redux store 的 一 致 和 统一 。 


做 了 这 么 多 改动 ， 是 时 候 看 看 效果 了 ， 如 图 5-9 所 示 。 











(©) redux blog 


€ © | 127.0.0.1:8080/#/?_k=z1bqnz 





Home 


Home 


Loading... 














图 5-9 ”应 用 界面 


虽然 界面 看 起 来 只 是 多 了 一 个 Loading 状态 , 但 实际 上 我 们 已 经 完成 了 Redux 应 用 绝 大 部 分 
功能 的 连 线 搭桥 ， 剩 下 的 只 是 丰富 样式 和 业务 逻辑 。 














5.6.9 引入 Redux Devtools 


在 丰富 业务 逻辑 之 前 , 我 们 有 必要 先 在 项 目 中 引入 Redux 应 用 的 大 杀 央 Redux Devtools。 
在 Redux 中 ， 所 有 的 数据 变化 都 来 源 一 个 个 的 action， 因 此 ， 如 果 有 一 个 工具 能 方便 我 们 查看 
action 的 触发 记录 以 及 数据 的 更 改 情况 ， 我 们 就 可 以 非常 方便 地 对 应 用 进行 调试 。 好 消息 是 ， 
Redux 本 身 就 提供 了 这 样 强大 的 功能 。 

由 于 Devtools 并 没有 打包 到 Redux 包 中 ， 我 们 需要 单独 下 载 这 些 依 赖 : 








$ npm install --save-dev redux-devtools redux-devtools-log-monitor redux-devtools-dock-monitor 


这 里 我 们 不 仅 下 载 了 redux-devtools， 同 时 还 下 载 了 redux-devtools-log-monitor 和 redux-devtools- 
dock-monitor， 后 面 两 个 其 实 是 React 组 件 。Redux 作者 在 设计 Devtools 时 ， 特 意 将 模块 进行 了 
清晰 的 划分 ， 这 样 你 可 以 根据 自己 的 需要 选择 合适 的 monitor。 


现在 将 DevTools 初始 化 的 相关 代码 统一 放 在 src/redux/DevTools.js 中 : 
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import React from 'react'; 

import { createDevTools } from 'redux-devtools'; 
import LogMonitor from 'redux-devtools-log-monitor'; 
import DockMonitor from 'redux-devtools-dock-monitor'; 


const DevTools = createDevTools( 
<DockMonitor toggleVisibilityKey='ctrl-h’ 
changePositionKey='ctrl-q'> 
<LogMonitor theme='tomorrow' /> 
</DockMonitor> 


); 
export default DevTools; 
DockMonitor 决定 了 DevTools 在 屏幕 上 显示 的 位 置 ， 我 们 可 以 按 Control+Q 键 切 换 位 置 ， 或 


者 按 Control+H 键 隐 藏 DevTool。 而 LogMonitor 决 定 了 DevTools 中 显示 的 内 容 , 默 认 包含 了 action 
的 类 型 、 完 整 的 action 参数 以 及 action 处 理 完 成 后 新 的 state。 效 果 如 图 5-10 所 示 。 
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Home Reset Revert 


H ome @@INIT 


Loading.… home: 和 1 key 
ing: 和 1 key 


@@router/LOCATION_CHANGE 


i: 和 8 keys 


: :入 1 key 
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图 5-10 Redux DevTools 


引入 Redux DevTools 后 ， 极 大 地 简化 了 我 们 对 于 整个 应 用 状态 的 推导 工作 。 因 为 我 们 能 看 
到 每 次 action 的 完整 信息 , 以 及 action 处 理 之 后 的 state， 文 些 state 又 被 connect 后 用 于 React 组 
件 的 泻 染 ， 最 终 呈 现在 用 户 界 面 上 。 





5.6.10 ”利用 middleware 实现 Ajax 请 求 发 送 
事实 上 ， 当 在 浏览 器 中 预览 我 们 的 Redux 应 用 时 ， 你 会 发 现 这 样 一 个 错误 信息 : 





Uncaught Error: Actions may not have an Undefined "type" property. Have you misspelled a constant? 


这 是 因为 Redux 没有 正确 识别 我 们 在 views/Home/PreviewListRedux.js 中 定义 的 LoadArticles() 
方法 返回 的 action。 
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在 5.2 节 中 ， 我 们 已 经 介绍 了 如 何 使 用 redux-composable-fetch 这 个 middleware 实现 异步 请 
现在 只 需要 引入 这 个 middleware 并 把 它 传 给 store 增强 器 即 可 。 


让 我 们 回顾 一 下 configurestore 的 实现 : 














求 





> 


import { createStore, combineReducers, compose, applyMiddleware } from 'redux'; 
import { routerReducer } from 'react-router-redux'; 


import ThunkMiddleware from 'redux-thunk'; 

// 引入 请 求 middleware 的 工厂 方法 

import createFetchMiddleware from 'redux-composable-fetch'; 
import rootReducer from './reducers'; 


// 创建 一 个 请 求 middleware 的 示例 
const FetchMiddleware = createFetchMiddleware(); 


const finalCreateStore = Compose( 


applyMiddleware( 
ThunkMiddleware, 
// 将 请 求 middleware 注入 store 增强 器 中 
FetchMiddleware 
) 
) (createStore); 


const reducer = combineReducers(Object.assign({}, rootReducer, { 
routing: routerReducer, 


})); 


export default function configureStore(initialState) { 
const store = finalCreateStore(reducer, initialState); 


return store; 


} 
这 样 ， 我 们 的 应 用 就 能 正确 识别 任何 异步 请 求 的 action 了 。 


5.6.11 请求 本 地 的 数据 
由 于 我 们 的 博客 系统 需要 通过 异步 请 求 获取 数据 ,而 为 了 减少 不 必要 的 干扰 , 我 们 并 不 会 具 
体 实现 一 个 服务 端 程序 来 响应 这 些 数 据 。 因 此 ， 一 个 可 行 的 方式 是 在 本 地 模拟 这 些 结果 。 


前 面 说 到 , 我 们 可 以 利用 webpack-dev-server 在 本 地 启动 一 个 简单 的 http 服务 器 来 响应 页 面 ， 
这 里 同样 可 以 利用 这 一 特性 伪造 一 些 本 地 数据 : 














src/ 
api/ 
articles.json 文章 列表 
article/ 
1.json id 为 1 的 文章 信息 ， 以 此 类 推 
2.json 


3.json 
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这 样 我 们 在 访问 http://127.0.0.1:8080/api/articles.json 时 ， 其 实 访问 的 是 我 们 在 本 地 定义 的 
JSON 文件 ， 而 不 是 远程 服务 器 的 接口 。 这 个 技巧 在 本 地 开发 前 端 代 码 时 会 经 常用 到 。 








说 明 如果 你 不 能 通过 上 述 链接 正常 访问 到 存储 在 本 地 的 JSON 文件 ,请 确保 执行 webpack-dev- 
server 命令 时 添加 了 --content-base . 参数 。 


我 们 在 articles.json 中 模拟 了 如 下 的 数据 结构 : 


{ 
[ 
"id": 1， 
"title": "Angular2 中 那些 我 看 不 懂 的 地 方 "， 
"description": "博客 停 更 了 近 3 个 月 ， 实 在 是 愧 对 很 多 在 微 博 上 推荐 的 同学 。 因 为 最 近 大 部 分 时 间 都 投入 
在 公司 里 一 个 比较 复杂 的 项 目 中 ， 直 到 本 周 才 算 正式 发 布 ， 稍 得 解脱 。 说 这 个 项 目 复杂 ， 不 仅 是 因为 需求 设 
计 复 杂 ， 更 是 因为 在 这 个 [...]"， 
"date": "2016-04-17" 
]， 
} 





看 看 自动 刷新 的 浏览 器 里 面 ， 一 个 博客 的 雏形 是 否 已 经 展示 出 来 了 ? 如 岁 5-11 所 示 。 





人 redux blog 
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Home 


Angular2 中 那些 我 看 不 懂 的 地 方 





2016-04-17 


博客 停 更 了 近 3 个 月 ， 实 在 是 愧 对 很 多 在 微 情 上 推荐 的 同学 。 因 为 最 近 大 部 分 时 间 
都 投入 在 公司 里 一 个 比较 复杂 的 项 目 中 ， 直 到 本 周 才 算 正式 发 布 ， 稍 得 解脱 。 说 
这 个 项 目 复杂 ， 不 仅 是 因为 需求 设计 复杂 ， 更 是 因为 在 这 个 [..] 
记 一 次 使 用 git bisect 快速 定位 bug 的 过 程 


2016-01-19 


图 5-11 应 用 界面 





5.6.12 页面 之 间 的 跳 转 

现在 博客 的 首页 已 经 初 见效 果 , 下 一 步 就 是 要 实现 文章 详情 页 了 。 首 先 要 考虑 的 问题 是 , 用 
户 怎么 进入 文章 详情 页 ?当然 是 点 击 链接 。 

前 面 讲 到 Navjs 时 ， 已 经 领略 了 使 用 ReactRouter 提供 了 <Link> 组 件 模拟 链接 的 做 法 ， 但 是 
在 Redux 应 用 中 ， 路 由 状态 也 属于 整个 应 用 状态 的 一 部 分 ， 所 以 更 合理 的 方案 应 该 是 通过 分 发 
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action 来 更 新 路 由 。 
在 这 一 节 中 ， 我 们 会 讲述 怎样 实现 通过 分 发 action 的 方法 完成 Redux 应 用 的 路 由 更 新 。 
由 于 React Router 本 身 是 一 个 独立 的 路 由 处 理 库 ， 要 想 把 React Router 中 维持 的 状态 暴露 给 


Redux 应 用 ， 或 是 在 Redux 应 用 中 修改 React Router 的 状态 ， 我 们 需要 某 种 手段 将 这 二 者 结合 起 
来 ， 这 就 要 说 到 react-router-redux 中 提供 的 routerMiddleware 了 : 





























// redux/configureStore.js 
import { hashHistory } from 'react-router'; 
import { routerMiddleware } from 'react-router-redux'; 


import rootReducer from './reducers'; 


const finalCreateStore = Compose( 
applyMiddleware( 
// 引入 其 他 middleware 
VS A 
// 引入 react-router-redux 提供 的 middleware 
routerMiddleware(hashHistory) 


) 


) (createStore); 


引入 了 新 的 middleware 之 后 ， 就 可 以 像 下 面 这 样 简单 修改 当前 路 由 了 : 








import { push } from 'react-router-redux'; 


// 在 任何 可 以 拿 到 store.dispatch 方法 的 环境 中 
store.dispatch(push('/')); 


既然 做 好 了 准备 工作 ， 让 我 们 对 文章 列表 页 组 件 进行 小 小 的 修改 ， 以 便 完成 路 由 跳 转 : 




















// components/Home/Preview.js 
import React, { Component, PropTypes } from 'react'; 


class Preview extends Component { 
static propTypes = { 
title: PropTypes.string, 
Link: PropTypes.string, 
push: PropTypes.func， 
}; 


handleNavigate(id, e) { 
// 阻止 原生 链接 跳 转 
e.preventDefault(); 


// 使 用 react-router-redux 提供 的 方法 跳 转 ， 以 便 更 新 对 应 的 store 
this.props.push(id); 
} 


render() { 
return ( 
<article className="article-preview-item"> 
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<h1 className="title"> 
<a href={* /detail/${this.props.id}’} onClick={this.handleNavigate.bind(this, 
this.props.id)}> 
{this.props.title} 
</a> 
</h1> 
<span className="date">{this.props.date}</span> 
<p className="desc">{this.props.description}</p> 
</article> 
); 
} 
} 


显而易见 的 变化 是 , 我 们 在 原本 的 标题 中 添加 了 链接 , 并 指定 了 点 击 链接 时 由 handleNavigate 
方法 来 响应 。 在 handleNavigate 方法 中 ， 首 先 执行 e.preventDefault() 来 阻止 原始 的 链接 跳 转 ， 
然后 调用 了 一 个 之 前 并 不 存在 的 this.props.push 方法 ， 它 就 是 用 来 处 理 路 由 的 更 新 的 。 


由 于 PreviewList 本 身 是 一 个 对 Redux 无 感知 的 展示 型 组 件 ， 所 以 它 并 不 能 直接 获取 到 store 
的 引用 ,也 就 无 法 使 用 store.dispatch 方法 来 随意 分 发 action。 因 此 , 我 们 需要 给 PreviewList 传 
递 一 个 绑 定 好 dispatch 的 push 方 法 ,让 它 直 接 调用 即 可 。 那 么 ,哪里 可 以 直接 拿 到 store.dispatch 
呢 ? 很 简单 ， 所 有 使 用 connect 方法 的 组 件 都 可 以 感知 Redux: 









































// views/Home.js 

import React, { Component } from 'react'; 

import { bindActionCreators } from 'redux'; 

import { connect } from 'react-redux'; 

import PreviewList from '../components/Home/PreviewList'; 
import { listActions } from './HomeRedux'; 

import { push } from 'react-router-redux'; 


class Home extends Component { 
render() { 
return ( 
<div> 
<h1>Home</h1> 
<PreviewList 
{...this.props.list} 
{...this.props.listActions} 
push={this.props.push} 
/> 
</div> 
); 
} 
} 


export default connect(state => { 
return { 
list: state.home.List， 
}; 
}, dispatch => { 
return { 
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listActions: bindActionCreators(listActions, dispatch), 
push: bindActionCreators(push, dispatch), 


}) (Hone); 


我 们 在 Home.js 中 引入 了 react-router-redux 提供 的 push 方法 ， 将 其 和 store.dispatch 绑 定 
后 ,作为 props 传 给 了 PreviewList。 因 为 在 PreviewList 里 并 没有 任何 直接 修改 路 由 的 需要 ， 所 以 
PreviewList 又 将 push 传递 给 了 Preview。 这 样 ， 我 们 在 Preview 里 就 可 以 通过 this.props.push() 
来 修改 路 由 了 。 


现在 点 击 其 中 一 个 链接 ， 看 看 Redux Devtools 中 记录 了 怎样 的 action ， 如 图 5-12 所 示 。 








Reset Revert 


LOAD_ARTICLES_SUCCESS 
和 3 keys 
» home: {1 1 key 
和 1 key 


eerouterVLOCATION_CHANGE 


| "/detail/1" 

















图 5-12 ”应 用 界面 
可 以 看 到 ， 在 地 址 栏 中 我 们 的 路 由 已 经 发 生 了 改变 ，Redux Devtools 也 为 我 们 记录 下 了 这 次 
action。 但 是 ， 界 面 看 起 来 不 太 正 常 吧 ? 那 是 因为 我 们 还 没有 在 Detail 组 件 中 写 任 何 逻 辑 。 


当 我 们 点 击 一 篇 博文 的 链接 进入 详情 页 时 ， 应 用 应 该 根据 当前 路 由 中 博文 的 id 请 求 对 应 的 
详细 数据 。 由 于 详情 页 中 的 逻辑 与 列表 页 并 没有 太 大 的 差别 ， 这 里 就 不 再 给 出 详细 的 代码 了 。 






































5.6.13 ”优化 与 改进 

Redux DevTools 虽然 功能 强大 , 但 是 这 样 的 工具 绝对 不 应 该 出 现在 生产 环境 中 。 因 为 它 不 仅 
增加 了 最 终 打包 JavaScript 文件 的 大 小 ， 更 会 很 大 程度 地 影响 整个 应 用 的 性 能 。 

所 以 , 我 们 希望 调整 代码 以 及 构建 脚本 ， 最 终 实 现在 开发 环境 中 加 载 Redux DevTools， 而 在 
生产 环境 中 不 进行 任何 加 载 。 

要 实现 这 样 的 需求 ， 首 先 需要 添加 一 款 webpack 的 插件 一 DefinePlugin， 这 款 插件 允许 我 
们 定义 任意 的 字符 串 ， 并 将 所 有 文件 中 包含 这 些 字符 串 的 地 方 都 蔡 换 为 指定 值 。 
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其 次 ， 我们 需要 了 解 一 种 常见 的 定义 Nodejs 应 用 环境 的 方法 一 一 环境 变量 。 一 般 意 义 上 来 
说 , 我们 习惯 使 用 process .env.NODE_ENV 这 个 变量 的 值 来 确定 当前 是 在 什么 环境 中 运行 应 用 。 当 
读 取 不 到 该 值 时 ， 默 认 当 前 是 开发 环境 ; 而 当 process.env.NODE_ENV=production 时 ， 我 们 认为 
当前 是 生产 环境 。 

掌握 这 两 点 知识 后 ， 只 需要 在 代码 中 添加 合适 的 判断 语句 , 最终 webpack 会 根据 不 同 的 环境 
帮 我 们 将 判断 语句 中 的 条 件 换 为 可 以 直接 求 值 的 表达 式 。 而 在 生产 环境 中 ， 配 合 男 一 款 插件 
UglifyJS 的 无 用 代码 移 除 功能 ， 可 以 方便 地 将 任何 不 必要 的 依赖 统统 移 除 。 比 如 ， 下 面 的 代码 在 
开发 环境 是 这 样 的 : 




















if (process.env.NODE_ENV === 'production') { 
// 这 里 的 代码 只 会 在 生成 环境 执行 

} elsef{ 
// 这 里 的 代码 只 会 在 开发 环境 执行 

} 


当 在 生产 环境 构建 时 ， 代 码 将 先 被 转化 为 : 
if (true) { 

// 这 里 的 代码 只 会 在 生成 环境 执行 
} elsef{ 


// 这 里 的 代码 只 会 在 开发 环境 执行 
} 


并 最 终 进 一 步 转化 为 : 
// 这 里 的 代码 只 会 在 生成 环境 执行 


这 样 既 保证 了 不 同 环境 加 载 不 同 代码 的 灵活 性 , 又 保证 了 在 生产 环境 打包 时 最 小 程度 地 引入 
依赖 。 





























5.6.14 ”添加 单元 测试 
在 上 一 章 中 ， 我 们 学 习 了 如 何 使 用 Jest 测试 Flux 中 的 store。 虽 然 借 助 Jest 强大 的 mock 功 
能 可 以 实现 我 们 的 最 终 目 的 ， 但 是 那些 技巧 确实 会 让 新 手 们 感觉 有 点 摸 不 着 头脑 。 


这 种 疑惑 在 我 们 测试 Redux 中 的 reducer 时 将 不 复 存 在 ， 因 为 reducer 就 是 最 常见 也 是 最 纯洁 
的 函数 。 


因此 ,我 们 将 不 需要 任何 额外 的 模拟 或 设置 , 只 需要 选择 自己 喜欢 的 测试 运行 框架 和 断言 库 ， 
直接 完成 测试 用 例 并 执行 即 可 。 


这 里 以 测试 previewList 这 个 reducer 为 例 ， 让 我 们 看 看 具体 的 测试 代码 该 如 何 编写 : 





























import previewList, { LOAD_ARTICLES_SUCCESS } from '../src/components/Home/PreviewListRedux ' ; 


describe('Preview List Reducer', () => { 


258 第 5 章 深入 Redux 应 用 架构 





it('should propagate new articles when loaded', () => { 
const data = [{id: 1, title: 'test'}]; 
const result = previewList({ 
type: LOAD_ARTICLES_SUCCESS ， 
payload: data， 
]); 


expect(result.articleList).to.deep.equal(data); 
})); 
}); 
更 有 意思 的 是 ， 借 助 Redux 神奇 的 Devtools 以 及 其 优秀 的 扩展 能 力 ， 在 开源 社区 中 出 现 了 
一 个 可 以 “帮助 我 们 写 测试 ”的 Redux Devtools redux-test-recorder。 在 开启 这 个 Devtools 之 
后 ， 我 们 只 需要 按照 页 面 的 交互 方式 操作 一 遍 应 用 ， 就 能 自动 生成 reducer 的 单元 测试 代码 。 


到 这 里 , Redux 应 用 的 核心 概念 我 们 已 经 熟悉 得 差不多 了 。 接 下 来 , 暂时 忘掉 Redux 的 API、 
酷 炫 的 DevTools， 思 考 一 下 我 们 为 什么 需要 Redux? 

















5.7 小 结 











在 本 章 中 , 我 们 详细 介绍 了 Redux 应 用 架构 。 从 SPA 应 用 的 角度 讲述 了 如 何 构 建 一 个 Redux 
React 应 用 ， 并 对 Redux 、React Redux、Redux middleware 作 了 源码 解读 ， 希望 读 者 有 一 个 较 深 
层次 的 理解 。 


千里 之 行 ， 始 于 足下 ，Redux 应 用 架构 的 出 现 还 是 为 了 能 够 在 生产 环境 中 解决 更 加 复杂 的 业 
务 问题 。 在 下 一 章 中 ,我 们 将 着 重 阐述 Redux 在 复杂 应 用 中 是 如 何 发 挥 作用 的 。 
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上 线 一 年 以 来 ，Redux 在 npm 上 的 下 载 量 已 经 超过 了 300 万 次 ,使 用 Redux 完成 的 项 目 总 
数 正在 以 惊人 的 速度 上 升 。 为 什么 Redux 如 此 受 开发 者 的 喜爱 呢 ? 本 章 将 深入 Redux 场景 ， 结 
合 企业 级 应 用 场景 ， 讲 述 Redux 在 复杂 表单 应 用 开发 时 的 一 些 经 验 与 优化 。 


6.1 高 阶 reducer 

















在 Redux 架构 中 ，reducer 是 一 个 纯 函 数 ， 它 的 职责 是 根据 previousState 和 action 计算 出 
新 的 state。 在 复杂 应 用 中 ，Redux 提供 的 combineReducers 让 我 们 可 以 把 顶层 的 reducer 拆 分 成 多 
个 小 的 reducer， 分 别 独立 地 操作 state 树 的 不 同 部 分 。 而 在 一 个 应 用 中 ,很 多 小 粒度 的 reducer 往 
往 有 很 多 重复 的 逻辑 ， 那 么 对 于 这 些 reducer， 如 何 去 抽 取 公 用 逻辑 ， 减 少 代 码 宛 余 呢 ? 这 种 情 
况 下 ， 使 用 高 阶 reducer 是 一 种 较 好 的 解决 方案 。 

在 讲述 如 何 使 用 高 阶 reducer 抽取 公用 逻辑 之 前 ,我们 先 来 定义 高 阶 reducer 的 概念 。 我 们 之 
前 对 函数 式 编程 已 经 有 所 了 解 ， 知 道 高 阶 函 数 是 指 将 函数 作为 参数 或 者 返回 值 的 函数 。 

类 似 地 ， 高 阶 reducer 就 是 指 将 reducer 作为 参数 或 者 返回 值 的 函数 。 


有 没有 意识 到 combineReducers 其 实 就 是 一 个 高 阶 reducer。 因 为 combineReducers 就 是 将 一 
个 reducer 对 象 作 为 参数 ， 最 后 返回 顶层 的 reducer。 


下 面 我 们 将 以 两 个 典型 的 案例 给 大 家 讲述 高 阶 reducer 的 常见 使 用 方法 。 





















































6.1.1 reducer 的 复 用 


我 们 将 顶层 的 reducer 拆 分 成 多 个 小 的 reducer, 肯定 会 碰 到 reducer 的 复 用 问题 。 例如 有 A 和 
B 两 个 模块 ， 它 们 的 UI 部 分 相似 ， 此 时 可 以 通过 配置 不 同 的 props 来 区 别 它们 。 那 么 这 种 情况 
下 ，A 和 B 模块 能 不 能 共用 一 个 reducer 呢 ? 答案 是 否定 的 。 我 们 先 来 看 一 个 简单 的 reducer: 


Const LOAD_DATA = 'LOAD_DATA'; 
const initialState = { ... }; 
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function LoadData() { 
return { 
type: LOAD_DATA, 


}; 


function reducer(state = initialState, action) { 
switch (action.type) { 
case LOAD_DATA: 
return { 
...State, 
data: action.payload, 
}; 
default: 
return state; 
} 
} 


如 果 我 们 将 这 个 reducer 绑 定 到 A 和 B 这 两 个 不 同 的 模块 ， 造 成 的 问题 将 会 是 ， 当 A 模块 调 
用 LoadData 来 分 发 相应 的 action 时 ，A 和 B 的 reducer 都 会 处 理 这 个 action， 然 后 A 和 B 的 内 容 
就 完全 一 致 了 。 


这 里 我 们 需要 意识 到 ， 在 一 个 应 用 中 ,不 同 模块 间 的 actionType 必须 是 全 局 唯一 的 。 
因此 ， 要 解决 actionType 唯一 的 问题 ， 有 一 个 方法 就 是 通过 添加 前 绥 的 方式 来 做 到 : 
























































function generateReducer(prefix, state) { 
const LOAD_DATA = prefix + 'LOAD_DATA'; 


const initialState = { ...state, ... }; 


return function reducer(state = initialState, action) { 
switch (action.type) { 
case LOAD_DATA: 
return { 
...State, 
data: action.payload, 
}; 
default: 
return state; 
} 
}; 
} 


这 样 只 要 A 模块 和 B 模块 分 别 调用 generateReducer 来 生成 相应 的 reducer ， 就 能 解决 
reducer 复 用 的 问题 了 。 而 对 于 prefix， 我 们 可 以 根据 自己 的 项 目 结构 来 决定 ， 例 如 ${ 页 面 名 
称 }_${ 模 块 名 称 }。 只 要 能 够 保证 全 局 唯一 性 ， 就 可 以 写成 一 种 前 级 。 
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6.1.2 reducer 的 增强 


除了 解决 复 用 的 问题 ， 高 阶 reducer 的 另 一 个 重要 作用 就 是 对 原始 的 reducer 进行 增强 。 
redux-undo 就 是 典型 的 利用 高 阶 reducer 来 增强 reducer 的 例子 , 它 的 主要 作用 是 使 任意 reducer 变 
成 可 以 执行 撤销 和 重 做 的 全 新 reducer。 我 们 来 看 看 它 的 核心 代码 实现 : 


function undoable(reducer) { 

const initialState = { 
// 记录 过 去 的 state 
past: []， 
// 以 一 个 空 的 action 调用 reducer 来 产生 当前 值 的 初始 值 
present: reducer(undefined, {}),， 
// 记录 后 续 的 state 
future: [] 

}; 


























return function (state = initialState, action) { 
const { past, present, future } = state; 


switch (action.type) { 
case '@@redux-undo/UNDO': 
const previous = past[past.Length - 1]; 
Const newpast = past.slice(0, past.length - 1); 


return { 
past: newPast ， 
present: previous， 
future: [ present, ...future ] 
}; 
case '@@redux-undo/REDO': 
const next = future[0]; 
const newFuture = future.slice(1); 


return { 
past: [ ...past, present ]， 
present: next, 
future: newFuture 
}; 
default: 
// 将 其 他 action 委托 给 原始 的 reducer 处 理 
const newpPresent = reducer(present, action); 


if (present === newPresent) { 
return state; 


} 


return { 
past: [...past, present], 
present: newPresent， 
future: [] 

}; 
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}; 
} 


有 了 这 个 高 阶 reducer， 就 可 以 对 任意 一 个 reducer 进行 封装 ; 





import { createStore } from 'redux'; 


function todos(state = [], action) { 
switch (action.type) { 
case 'ADD_TODO': 
fs 
} 
} 


const undoableTodos = undoable(todos); 
const store = createStore(undoableTodos); 


store.dispatch({ 
type: 'ADD_TODO', 
text: 'Use Redux', 


}); 


store.dispatch({ 

type: 'ADD_TODO', 

text: 'Implement Undo', 
]); 


store.dispatch({ 
type: '@@redux-undo/UNDO', 
}: 


查看 高 阶 reducer undoable 的 实现 代码 可 以 发 现 ， 高 阶 reducer 主要 通过 下 面 3 点 来 增强 
reducer: 
口 能 够 处 理 额外 的 action; 
口 能 够 维护 更 多 的 state; 
口 将 不 能 处 理 的 action 委托 给 原始 reducer 处 理 。 




















6.2” Redux 与 表单 


React 单 向 绑 定 的 特性 极 大 地 提升 了 应 用 的 执行 效率 ， 但 是 相 比 于 简单 易 用 的 双向 绑 定 ， 单 
向 绑 定 在 处 理 表 单 等 交互 的 时 候 着 实 有 些 力不从心 。 具 体 到 React 应 用 中 ， 单 向 绑 定 意味 着 你 需 
要 手动 给 每 一 个 表单 控件 提供 onChange 回调 函数 ， 同 时 需要 将 它们 的 状态 初始 化 在 this.state 
中 。 不 仅 如 此 , 一 个 体验 友好 的 表单 还 需要 有 明确 的 错误 状态 和 错误 信息 ,甚至 某 些 输入 项 还 需 
要 异步 校 验 功 能 。 也 就 是 说 ， 表 单 里 的 一 个 有 效 字段 至 少 需要 2 ~ 3 个 本 地 状态 。 

在 Angularjs 中 ,表单 相关 的 问题 在 框架 层面 已 经 得 到 了 很 好 的 解决 。 那 么 ， 对 于 React+ 
Redux 应 用 ， 有 没有 什么 好 的 方案 呢 ? 
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下 面 我 们 将 从 两 个 层面 来 解答 这 个 问题 : 对 于 简单 的 表单 应 用 ， 为 了 减少 重复 元 余 的 代码 ， 
可 以 使 用 redux-form-utils 这 个 工具 库 ， 它 能 利用 高 阶 组 件 的 特性 为 表单 的 每 个 字段 提供 vatue 和 
onChange 等 必须 值 ， 而 无 需 你 手动 创建 ;对 于 复杂 的 表单 ， 则 可 以 使 用 redux-form。 虽 然 同样 基 
于 高 阶 组 件 的 原理 , 但 如 果 说 redux-form-utils 是 一 把 水 果 刀 的 话 , 那么 redux-form 就 是 一 把 多 功 
能 的 瑞士 军刀 。 除 了 提供 表单 必须 的 字段 外 ，redux-form 还 能 实现 表单 同步 验证 、 异 步 验证 甚至 
般 套 表单 等 复杂 功能 。 









































6.2.1 使 用 redux-form-utils 减少 创建 表单 的 宛 余 代 码 
了 解 redux-form-utils 之 前 ， 我 们 先 看 看 如 何 使 用 原生 React 处 理 表单 : 


import React, { Component } from 'react'; 


class Form extends Component { 
constructor(props) { 
super(props); 


this.handleChangeAddress = this.handleChangeAddress.bind(this); 
this.handleChangeGender = this.handleChangeGender .bind(this); 


this.state = { 
name: '! 
address: 
gender: 
}; 
} 


handleChangeName(e) { 
this.setState({ 
name: e.target.value, 
}); 
} 


handleChangeAddress(e) { 
this.setState({ 
address: e.target.value, 
}); 
} 


handleChangeGender(e) { 
this.setState({ 
gender: e.target.value, 
}); 
} 


render() { 
const { name, address, gender } = this.state; 
return ( 
<form className="form"> 
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<input name="name" value={name} onChange={this.handleChangeName} /> 

<input name="address" value={address} onChange={this.handleChangeAddress} /> 

<select name="gender" value={gender} onChange={this.handleChangeGender}> 
<option value="male" /> 
<option value="female" /> 

</select> 

</form> 
); 
} 


可 以 看 到 ， 虽 然 我 们 的 表单 里 只 有 3 个 字段 ， 但 是 已 经 有 非常 多 的 元 余 代 码 。 如 果 还 需要 加 
上 验证 等 功能 ， 那 么 这 个 表单 对 应 的 处 理 代码 将 会 更 加 膨胀 。 

仔细 分 析 表 单 的 代码 实现 ， 我 们 发 现 几乎 所 有 的 onchange 处 理 器 逻辑 都 很 类 似 ， 只 是 需要 
改变 表单 字段 即 可 。 对 于 某 些 复杂 的 输入 控件 ， 比 如 自己 封装 了 一 个 TimePicker 组 件 ， 也 许 回 
调 名 称 不 是 onChange， 而 是 onSelect。 同 样 ，onSelect 回调 里 提供 的 参数 也 许 并 不 是 React 的 合 
成 事件 ， 而 是 一 个 具体 的 值 。 通 过 分 析 表 单 控件 可 能 的 输入 和 输出 ， 我 们 将 通过 使 用 
redux-form-utils 减少 Redux 处 理 表单 应 用 时 的 匈 余 代码 : 















































// components/MyForm.js 
import React, { Component } from 'react'; 
import { createForm } from 'redux-form-utils'; 


@createForm({ 
form: 'my-form', 
fields: ['name', 'address', 'gender'], 
}) 
class Form extends Component { 
render() { 
const { name, address, gender } = this.props.fields; 
return ( 
<form className="form"> 
<input name="name" {...name} /> 
<input name="address" {...address} /> 
<select {...gender}> 
<option value="male" /> 
<option value="female" /> 
</select> 
</form> 
); 
} 
} 


可 以 看 到 ， 实 现 同样 功能 的 表单 ， 代 码 量 减少 了 近 一 半 以 上 。 

redux-form-utils 提供 了 两 个 方便 的 工具 函数 createForm(config) 和 bindRedux(config), 
前 者 可 以 当 作 decorate 使 用 ， 传 人 表单 的 配置 ， 自 动 为 被 装饰 的 组 件 添加 表单 相关 的 props; 而 
后 者 则 生成 与 Redux 应 用 相关 的 reducer 、initialState 和 actionCreator 等 。 
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下 面 先 看 看 如 何在 reducer 里 整合 redux-form-utils: 





// reducer/MyForm.js 
import { bindRedux } from 'redux-form-utils'; 


const { state: formState, reducer: formReducer } = bindRedux({ 
form: 'my-form', 
fields: ['name', 'address', 'gender'], 


}); 


const initialState = { 
foo: 1， 
bar: 2， 
...formState, 


}; 


function myReducer(state = initialState, action) { 
switch (action.type) { 
case 'MY_ACTION': { 


J 
} 


default: 
return formReducer(state, action); 
} 
} 
我 们 把 同样 的 配置 传 给 bindRedux 方法 ， 并 获得 这 个 表单 对 应 的 reducer 和 初始 状态 
formstate， 并 将 这 些 内 容 整 合 在 reducer 中 。 
完成 createForm 和 bindRedux 这 两 个 函数 后 ， 一 个 基于 Redux 的 表单 应 用 就 完成 了 。 为 了 


后 续 修 改 表单 更 加 灵活 ， 建 议 将 配置 文件 单独 保存 ， 并 分 别 在 组 件 和 reducer 中 引入 对 应 的 配置 
文件 。 








6.2.2 ”使 用 redux-form 完成 表单 的 异步 验证 


redux-form-utils 为 我 们 提供 了 实现 表单 最 基本 的 功能 ， 但 是 为 了 让 填写 表单 的 体验 更 加 友 
好 ， 在 把 数据 提交 到 服务 端 之 前 ， 我 们 应 该 做 一 些 基 本 的 表单 校 验 ， 比 如 必 填 字段 不 能 为 空 拉 
要 实现 校 验 等 更 复杂 的 表单 功能 ， 需 要 用 到 redux-form。 

在 使 用 和 配置 方面 ,redux-form 与 redux-form-utils 没有 太 多 的 差异 ,唯一 不 同 的 是 redux-form 
需要 在 Redux 应 用 的 state 树 中 挂 载 一 个 独立 的 节点 。 这 意味 着 ， 所 有 使 用 redux-form 创建 的 表 
单 中 的 字段 都 会 在 一 个 固定 的 位 置 ， 如 state.form.myForm 或 state.form.my0therForn 均 挂 载 在 
state.form 下 : 







































































import { createStore, combineReducers } from 'reduyx'; 
import { reducer as formReducer } from 'redux-form'; 
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中 


redux-form 进行 了 封装 ， 对 使 用 者 透明 。 


Const reducers = { 
// 其 他 的 reducer ... 
// 所 有 表单 相关 的 reducer 挂 载 在 form 下 
form: formReducer, 


} 


const reducer = combineReducers(reducers); 
const store = createStore(reducer); 


完成 了 基本 的 配置 后 ， 现 在 看 看 redux-form 如 何 帮 我 们 完成 表单 验证 功能 : 


import React, { Component } from 'react'; 
import { reduxForm } from 'redux-form'; 





function validate(values) { 


if (vaLues.name == null || values.name === '') { 
return { 
name: ' 请 填写 名 称 '， 
}; 
} 
} 
@reduxForm({ 


form: 'my-form', 
fields: ['name', 'address', 'gender'], 


validate, 
}) 
class Form extends Component { 
render() { 
const { name, address, gender } = this.props.fields; 
return ( 


<form className="form"> 
<input name="name" {...name} /> 
{ name.error && <span>{name.error}</span> } 
<input name="address" {...address} /> 
<select {...gender}> 
<option value="male" /> 
<option value="female" /> 
</select> 
<button type="submit"> 提 交 </button> 
</form> 
); 
} 
上 


在 上 面 的 表单 中 ， 我 们 在 提交 时 对 name 字段 做 了 非 空 验证 ， 而 在 Form 组 件 的 render 方法 
同时 添加 了 显示 相应 错误 的 逻辑 。 触 发 验证 、 重 新 渲染 、 表 单纯 洁 性 判断 等 过 程 ， 均 被 








a 











可 以 看 到 , 使 用 redux-form 校 验 表单 十 分 简单 易 用 , 从 很 大 程度 上 填补 了 Redux 应 用 在 框架 











层面 处 理 表单 应 用 的 不 足 。 
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6.2.3 ”使 用 高 阶 reducer 为 现 有 模块 引入 表单 功能 


在 前 面 两 节 中 , 我 们 学 到 了 如 何 使 用 redux-form-utils 及 redux-form 实现 表单 的 各 种 功能 。 但 
如 果 你 已 经 有 一 个 完整 的 Redux 应 用 , 如 何 能 在 最 小 改动 的 基础 上 添加 表单 相关 的 功能 呢 ? 其 中 
一 种 方案 是 6.1 节 中 提 到 的 技术 。 

鉴于 redux-form-utils 和 redux-form 均 没 有 提供 类 似 的 功能 , 我 们 需要 用 到 开源 社区 的 另外 一 
个 React Redux 表单 实现 


假设 你 的 reducer 中 已 经 写 好 了 如 下 逻辑 : 


// MyReducer.js 

const initialState = { 
firstName: '', 
lastName: '' 
fullName: ''， 


}; 


























react-redux-form 。 


function myReducer(state = initialState, action) { 
switch (actions.type) { 
case 'GET_FULL_NAME': 
return { 
...State, 
fullName: ‘${state.firstName} S${state.lastName}, 
}; 
default: 
return state; 
} 
} 


如 果 想 要 利用 react-redux-form 提供 的 表单 功能 ， 则 需要 引入 一 个 高 阶 reducer 
用 它 来 装饰 我 们 的 myReducer: 


import { modeled } from 'react-redux-form'; 

















modeled ， 








const initialState = /* ... */ 

function myReducer(...) { 
Ja/ 

} 


// 为 我 们 的 reducer 提供 处 理 表 单 的 能 力 


Const myModeledReducer = modeled(myReducer, 'my'); 


export default myModeledReducer; 


装饰 完成 后 ， 当 你 想 要 修改 定义 在 这 个 reducer 里 的 状态 ， 则 需要 用 到 react-redux-form 的 
actions.change 方法 : 





import { actions } from 'react-redux-form'; 
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let state = { firstName: 'Daniel', lastName: 'Walker' }; 


let newState = myModeledReducer(state, actions.change('my.firstName', 'Johnnie')); 


// => { firstName: 'Johnnie', lastName: 'Walker' } 


可 以 看 到 ， 使 用 react-redux-form 的 高 阶 reducer 可 以 简单 快捷 地 为 red 
理 的 能 力 ， 而 无 需 对 现 有 的 代码 及 结构 进行 大 幅 的 修改 。 








6.3 Redux CRUD 实战 





ucer 代码 添加 表单 处 


在 实际 业务 的 开发 过 程 中 ， 少 不 了 搭建 各 种 各 样 的 后 台 管理 应 用 ， 而 这 一 类 应 用 的 核心 功 





能 之 一 就 是 “ 增 、 删 、 改 、 查 (CRUD )。 我 们 在 上 一 节 中 如 何 介绍 了 使 月 














日 redux-form-utils 和 


redux-form 完成 简单 和 复杂 的 表单 类 应 用 开发 , 在 本 节 中 , 我 们 将 实现 一 个 小 型 但 功能 完备 的 增 、 
删 、 改 、 查 应 用 。 为 了 完成 这 个 应 用 ， 我 们 还 需要 用 到 Ant Design 中 的 Table 及 Modal 组 件 。 





6.3.1 准备 工作 


在 开始 具体 的 增 、 删 、 改 、 查 逻辑 之 前 , 先 按照 第 5 章 中 的 Redux 应 用 架构 初始 化 一 个 项 目 ， 


其 目录 结构 如 下 : 


上 一 api 

| Larticles.json 
上 一 index.html 

上 一 package.json 

src 

| 一 app.js 

| 一 components 


| 

| 一 

| -一 DevTools.js 

| 上 一 configureStore.dev.js 
| 上 一 configureStore.js 

| 上 一 configureStore.prod.js 
| reducers.js 

上 一 routes 

上 -一 index.js 


上 一 Home.css 
-一 Home.js 


-一 HomeRedux.js 
[一 webpack.config js 


在 第 5 章 的 基础 上 ， 我 们 需要 额外 依赖 antd 和 redux-form-utils 这 两 个 npm 包 ， 其 中 antd 即 
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为 Ant Design 提供 的 一 系列 优秀 React 组 件 的 集合 。 也 正 因 此 ， 我 们 还 需要 在 index.html 中 引入 
对 应 的 样式 文件 。 


在 实际 开发 过 程 中 ， 建 议 使 用 Ant Design 提供 的 Babel 插件 babel-plugin-antd 来 实现 插件 和 
样式 的 按 需 加 载 。 


为 了 保持 简洁 ， 在 以 下 代码 片段 中 ， 我 们 将 省 略 部 分 样式 代码 : 
$ npm install -S antd redux-form-utils 


此 外 , 我们 依然 遵循 之 前 的 约定 ,在 本 地 的 /api 目录 模拟 服务 器 接口 。 因 此 ， 我们 的 应 用 操 
作 的 数据 对 象 将 是 文章 (article )。 


最 后 ， 将 多 余 的 /detail 相关 的 文件 删除 ， 并 将 components/Home/ 下 的 组 件 删 除 。 至 此 ， 我 
们 已 经 完成 了 应 用 的 架构 搭建 。 





























6.3.2 ”使 用 Table 组 件 完成 “ 查 ” 功 能 


增 、 删 、 改 、 查 中 ,实现 起 来 最 简单 的 可 能 就 是 “ 查 ” 了 。 通 常 ， 我 们 会 使 用 表格 组 件 来 展 
示 数 据 ， 配 合 输入 框 和 “搜索 ”按钮 实现 数据 的 搜索 和 过 滤 。 


首先 ， 我 们 在 components/Home/ 中 添加 Table 组 件 及 其 对 应 的 Redux 文件 : 


























STC/ 

上 一 appjs 

上 一 components 

| 上 -一 Home 

| 一 Table.js 

| TableRedux.js 
| 一 layouts 

| 一 Tedux 

上 一 routes 


LL views 


对 于 查询 需求 来 说 ， 首 先 需要 请 求 到 数据 。 因 此 ， 我 们 在 TableRedux 文件 中 需要 定义 请 求 6 
数据 的 action creator: 


// TableRedux.js 
function loadArticles() { 

return { 
url: '/api/articles.json', 
types: ['LOAD_ARTICLES', 'LOAD ARTICLES_ SUCCESS', 'LOAD_ARTICLES_ ERROR'], 
}; 
} 





说 明 如果 你 对 这 样 的 action 格式 感到 疑惑 ， 请 参考 5.3 节 。 
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以 及 响应 action 的 reducer: 


// TableRedux.js 

const initialState = { 
articles: []， 
loading: true, 
error: false, 


}; 


function articles(state = initialState, action) { 
switch (action.type) { 
case 'CHANGE QUERY': { 
return { 
...State, 
query: action.payLoad.query， 
}; 
中 


case 'LOAD_ARTICLES': { 
return { 
...State, 
loading: true, 
error: false, 
}; 
} 


case 'LOAD_ARTICLES_SUCCESS': { 
return { 
...State, 
articles: action.payload, 
loading: false, 
error: false, 
}; 
} 


case 'LOAD_ARTICLES_ERROR': { 
return { 
sotatey 
loading: false, 
error: true, 
}; 
站 


default: 
return state; 


} 
} 


上 述 reducer 中 的 代码 ， 指 定 了 在 请 求 数 据 中 、 请 求 数 据 成 功 及 请 求 失败 3 种 状态 下 reducer 
应 该 怎样 修改 状态 的 逻辑 。 


接 下 来 ,我 们 需要 一 个 组 件 来 展示 请 求 到 的 数据 : 
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// components/Home/Table.js 
import React, { Component, PropTypes } from 'react'; 
import { Table } from 'antd'; 


const columns = [{ 


title: ' 标 题 '， 

dataIndex: 'title', 
},{ 

title: ' 描 述 '， 

dataIndex: 'desc', 
},{ 


title: ' 发 布 日 期 '， 
dataIndex: 'date', 


}]; 
class ArticleTable extends Component { 
render() { 
return ( 
<Table columns={columns} data={this.props.articles} /> 
); 
} 


~ 
export default ArticleTable; 
下 面 在 views 中 应 用 这 些 逻 辑 。 


首先 ， 我们 需要 在 views/HomeRedux.js 中 引入 已 经 定义 好 的 reducer 和 actionCreator ， 并 按 
照 约 定好 的 规则 统一 输出 : 
// views/HomeRedux.js 


import tableReducer from '../components/Home/TableRedux'; 
import { combineReducers } from 'redux'; 





export default combineReducers({ 
table: tableReducer, 
]); 





export * as tableActions from '../components/Home/TabLeRedux ' ; 
同时 在 人 口 的 views 页 面 中 关联 数据 源 并 泻 染 对 应 的 组 件 : 


// views/Home.js 

import React, { Component } from 'react'; 

import { connect } from 'react-redux'; 

import ArticleTable from '../components/Home/Table'; 
import { tableActions } from './HomeRedux'; 


@connect(state => ({ 
table: state.articles.table, 

}), { tableActions }) 

class ArticleCRUD extends Component { 
render() { 
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return ( 
<div className="page"> 
<ArticleTable {...this.props.table} {...this.props.tableActions} /> 
</div> 
); 
} 
上 


export default ArticleCRUD; 


到 这 一 步 , 我 们 已 经 完成 了 最 基础 的 数据 展示 操作 。 要 真正 实现 “ 查 ”, 还 需要 加 入 搜索 功能 : 





// components/Home/Table.js 
import React, { Component, PropTypes } from 'react'; 
import { Table } from 'antd'; 


const columns = [{ 


title: ' 标 题 '， 
dataIndex: 'title', 
}, { 


title: ' 描 述 '， 

dataIndex: 'desc', 
}, { 

title: ' 发 布 日 期 '， 

dataIndex: 'date', 
}]; 


class ArticleTable extends Component { 
render() { 
return ( 
<div className="table"> 
<div className="search"> 
<input 
type="text" 
placeholder=" 请 输入 关键 字 " 
value={this.props.query} 
onChange={this .props.changeQuery} 
/> 
<button onClick={this.props.search}> 搜 索 </button> 
</div> 
<Table 
columns={columns} 
data={this.props.articles} 
/> 
</div> 
); 
} 
. 


export default ArticleTable; 


我 们 在 ArticleTable 组 件 中 添加 了 一 个 简单 的 搜索 框 和 “搜索 ”按钮 , 下 面 看 看 对 应 的 reducer 
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及 actionCreator 实现 : 


// TableRedux.js 

const initialState = { 
articles: []， 
loading: true, 
error: false, 
query: '', 


}; 


function changeQuery(e) { 
return { 
type: 'CHANGE_QUERY', 
payload: { 
query: e.target.value.trim(), 
}, 
}; 
} 


function search() { 
return (dispatch, getState) => { 
const { query } = getState().articles.table; 
return dispatch(loadArticles(query)); 
} 
} 


function loadArticles(query) { 
return { 

大 这 

}; 

} 


function articles(state = initialState, action) { 
switch (action.type) { 
case 'CHANGE_QUERY': { 
return { 
...State, 
query: action.payload.query, 
}; 
} 





1 


default: 
return state; 


} 
} 


因为 新 增 了 搜索 框 ,， 所 以 我 们 需要 多 维护 一 个 状态 来 表示 当前 已 经 输入 搜索 词 ,以 及 修改 这 
个 状态 所 对 应 的 actionCreator 和 reducer。 
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其 次 ， 利 用 现 有 的 接口 ， 添 加 query 参数 实现 搜索 的 效果 。 为 了 代码 复 用 ， 实 现 搜索 功能 的 
search 方法 并 没有 具体 的 发 请 求 逻 辑 ， 而 是 调用 了 初始 化 时 的 加 载 方法 。 而 对 于 初始 化 时 的 加 载 
方法 ， 我 们 进行 了 小 小 的 改造 ， 以 兼容 有 无 query 参数 这 两 种 场景 。 

至 此 ,最 简单 的 “ 查 ” 操 作 就 完成 了 ,效果 如 图 6-1 所 示 。 


Home 


输入 关键 字 eT 

















标题 描述 发 布 日 期 


样 例文 章 1 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 2016-04-17 
例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 


样 例文 章 2 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 ”2016-01-19 
四 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 


样 例文 章 3 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 2016-01-02 
例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 


样 例文 章 4 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 OTe Ti 
例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 



































样 例文 章 5 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 2015-10.25 
例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 这 是 样 例 的 内 容 。 





图 6-1 “ 查 ” 操 作 界 面 


6.3.3 ”使 用 Modal 组 件 完成 “ 增 ” 与 “ 改 ” 


新 增 一 条 数据 时 ,通常 会 弹出 一 个 对 话 框 ,此 时 需要 在 里 面 输 入 所 有 的 必 填 字段 。 而 修改 这 
条 数据 时 ， 需 要 自动 填充 所 有 字段 对 应 的 值 ， 以 及 一 个 隐藏 的 i4， 以 实现 修改 的 效果 。 


让 我 们 按照 Table 的 方式 为 Modal 初始 化 代码 : 





src/ 
上 一 app.js 
components 
| Home 
| HF Modaljs 
| 广 一 ModalRedux.js 
| Co Tablejs 
| LTableRedux.js 
上 一 layouts 
Oo redux 
[一 routes 


[一 views 


在 Modal 中 ， 可 以 利用 redux-form-utils 或 redux-form 来 简化 表单 输入 流程 。 本 节 使 用 
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redux-form-utils 来 实现 这 个 功能 : 


// components/Home/Modal.js 

import React, { Component, PropTypes } from 'react'; 
import { Modal } from 'antd'; 

import { createForm } from 'redux-form-utils'; 
import formConfig from './Modal.config'; 


@createForm(formConfig) 
class ArticleModal extends Component { 
render() { 
const { title, desc, date } = this.props.fields; 
return ( 
<Modal 
isVisible={this.props.isVisible} 
onCanceL={fthis.props.onCanceL} 
on0k={this.props.on0k} 


<div className="form"> 
<div className="control-group"> 


<LabeL> 标 题 </LabeL> 
<input type="text" {...title} /> 
</div> 
<div className="control-group"> 
<LabeL> 描 述 </LabeL> 
<textarea {...title} /> 
</div> 


<div className="control-group"> 
<LabeL> 发 布 日 期 </LabeL> 
<input type="date" {...title} /> 
</div> 
</div> 
<button onClick={this.props.onOk}> 确 认 </button> 
<button onClick={this.props.onCancel}> 取 消 </button> 
</Modal> 
); 
} 
} 


export default ArticleModal; 


而 ModalRedux 中 初始 化 的 逻辑 与 上 一 节 类 似 ， 此 处 不 再 袭 述 。 下 面 着 重 看 看 表单 填写 完成 


后 ,怎样 向 服务 端 提交 数据 : 


// components/Home/ModalRedux.js 
function addArticle() { 
return (dispatch, getState) => { 
const { title, desc, date } = getState().article.modal.form; 


return dispatch({ 
url: '/api/articles.json', 
method: 'POST', 
params: { 
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title: title.value, 
desc: desc.value, 
date: date.value, 
}， 
]); 
}; 
} 


在 实现 Modal 的 自身 逻辑 后 我们 将 其 整合 到 页 面 中 ， 并 添加 显示 对 话 框 的 逻辑 : 





// views/Home.js 

import React, { Component } from 'react'; 

import { connect } from 'react-redux'; 

import ArticleTable from '../components/Home/Table'; 
import ArticleModal from '../components/Home/Modal'; 
import { tableActions, modalActions } from './HomeRedux ' ; 


@connect(state => { 
return { 
table: state.articles.table, 
modal: state.articles.modal, 


}; 
}, { 
tableActions, 
modalActions, 
}) 
class ArticleCRUD extends Component { 
render() { 
return ( 
<div className="page"> 
<button onClick={this.props.modalActions.showModal}> 新 增 文 章 </button> 
<ArticleTable {...this.props.table} {...this.props.tableActions} /> 
<ArticleModal {...this.props.modal} {...this.props.modalActions} /> 
</div> 
); 
} 


} 


export default ArticleCRUD; 


效果 如 图 6-2 所 示 。 
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标题 


描述 


发 布 日 期 yyyy-mm-dd 





图 6-2 新 增 数据 界面 


6.3.4 ” 巧 用 Modal 实现 数据 的 删除 确认 


用 户 在 进行 删除 操作 前 , 一 个 友好 的 提示 框 能 够 避免 许多 误 删 的 情况 。 但 是 这 样 给 开发 者 带 
来 了 新 的 烦恼 ， 即 需要 维护 的 状态 太 多 。“ 对 话 框 是 否 打 开 ” 作 为 一 个 状态 还 在 忍受 范围 内 ,“ 删 
除 确认 对 话 框 ”是 否 显示 难道 也 要 作为 一 个 状态 吗 ? 

因此 ， 在 实际 的 开发 实践 中 ， 我 们 建议 对 此 类 一 次 性 、 非 持久 化 的 状态 ， 可 以 考虑 使 用 非 
Redux 的 状态 管理 系统 ， 如 promise， 甚 至 是 this.state 来 解决 。 


在 本 例 中 ， 我 们 将 利用 Ant Design 中 Modal 组 件 提 供 的 单 例 方 法 Modal.confirm() 来 完成 删 
除 确认 工作 ， 而 不 引入 一 个 新 的 状态 : 
function handleDelete(id) { 
Modal.confirm({ 
title: ' 提 示 '， 
content: ' 确 认 要 删除 这 篇 文章 吗 ?'， 


onOk() { 
// 分 发 删除 文章 对 应 的 action 6 
}, 


1 
} 


当然 ， 要 想 最 终 提 供 删 除 功能 ， 还 需要 在 表格 组 件 中 新 增 一 列 操作 区 域 ， 并 增加 对 应 的 “ 删 
除 ” 按 钮 : 


// components/Home/Table.js 
const columns = [{ 











title: ' 标 题 '， 

dataIndex: 'title', 
}, { 

title: ' 描 述 '， 


dataIndex: 'desc', 


}, { 
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title: ' 发 布 日 期 '， 
dataIndex: 'date', 
}, { 
title: ' 操 作 '， 
render(text, record) { 
return <a className="op-btn" onClick={this.handleDelete.bind(this, record)}> 删 除 </a>; 
]， 
}]; 


Ve ee 
handleDelete(record) { 
Modal.confirm({ 
title: ' 提 示 '， 
content: ' 确 认 要 删除 该 文章 吗 ?'， 
}).then(() => { 


this.props.deleteArticle(record); 


}); 
} 
render() { 
/es 
return ( 
<Table columns={columns.map(c => c.render ? ({ 
ee 
render: c.render.bind(this), 
}) : c)} dataSource={this.props.articles} /> 
); 
} 
效果 如 图 6-3 所 示 。 


侈 提示 


确认 要 删除 该 文章 吗 ? 





图 6-3 ”删除 确认 界面 


6.3.5” 善 用 promise 玩 转 Redux 异步 事件 流 


刚 接触 Redux 的 人 在 开发 Redux 应 用 时 ,感觉 最 头疼 的 地 方 英 过 于 任何 状态 的 修改 都 要 放 
在 reducer 中 来 处 理 。 虽 然 这 样 严格 的 要 求 确实 方便 管理 整个 应 用 的 状态 变更 ,但 是 对 于 某 些 我 
们 确定 不 会 有 副作用 的 状态 变更 ， 有 时 候 使 用 promise 来 管理 会 更 加 简单 、 流 畅 。 如 果 能 够 熟练 
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运用 这 一 技巧 ， 能 让 你 的 Redux 应 用 开发 效率 得 到 明显 提升 。 


























以 上 一 节 中 “删除 一 篇 文章 的 需求 ”为 例 ， 当 用 户 点 击 “ 删 除 ” 按 钮 时 ， 首 先 会 弹出 对 话 杠 





询问 用 户 是 否 确认 要 删除 ， 若 用 户 点 击 “ 确 定 ” 按 钮 ,由 
用 户 体验 ， 我 们 应 该 反馈 删除 操作 是 否 成 功 。 

















| 发 送 删除 文章 的 请 求 。 如 果 考 虑 更 好 的 


如 果 使 用 reducer 来 管理 状态 ， 至 少 需要 记录 “删除 确认 对 话 框 是 否 弹出 ”和 “删除 请 求 发 
送 状态 (发送 中 、 成 功 、 失 败 》 这 4 个 状态 。 如 果 换 用 基于 promise 的 处 理 方式 呢 ? 





ff 
handleDelete(record) { 
Modal.confirm({ 
title: ' 提 示 '， 
content: ' 确 认 要 删除 该 文章 吗 ?'， 
onOk() { 
this.props.deleteArticle(record).then(() => { 
Modal.alert({ 
title: ' 提 示 '， 
content: ' 删 除 成 功 '， 
}); 
}, (err) => { 
Modal.alert({ 
title: ' 提 示 '， 
content: “删除 失败 ' ， 
]); 


可 以 看 到 ， 我 们 在 之 前 例子 的 基础 上 添加 了 一 段 promise 的 逻辑 ， 而 这 段 逻辑 居然 添加 在 发 
送 请 求 的 actionCreator 调用 之 后 。 这 是 怎么 做 到 的 呢 ? 事实 上 , 这 是 redux-composable-fetch 通 
过 利用 Redux 中 dispatch 方法 会 返回 被 处 理 的 action 这 一 设计 ， 巧 妙 地 将 实现 异步 请 求 的 


promise 返回 给 调用 者 来 实现 的 。 





经 过 改造 ， 我 们 在 一 个 方法 中 就 完成 了 若干 个 状态 的 判断 及 处 理 ， 不 可 谓 不 简单 高 效 。 


需要 特别 说 明 的 是 ， 基 于 promise 的 异步 事件 流 处 至 


对 于 Redux 应 用 来 说 是 一 种 反 模 式 ， 








此 在 实际 开发 过 程 中 , 一 定 要 对 哪些 场景 可 以 使 用 这 种 模式 作出 清晰 的 判断 。 可 供 参考 的 条 件 有 : 
这 个 状态 的 修改 是 否 会 影响 到 其 他 模块 ?” 这 个 状态 是 否 会 通过 其 他 模块 初始 化 ? 如 果 答 案 都 是 









































否定 的 ， 那 么 你 就 可 以 安心 地 使 用 promise 模式 了 。 


6.4 ”Redux 性 能 优化 








在 Redux 架构 的 应 用 中 , 数据 流动 清晰 明了 , 但 是 在 数据 流动 中 也 出 现 了 许多 不 必要 的 重复 
计算 和 泻 染 。 因 次 ,我 们 需要 避免 这 些 “ 重 复 ”来 优化 性 能 。 
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6.4.1 Reselect 
在 Redux 中 ， 通 常 称 store 中 的 数据 为 “ 源 数 据 "。 我 们 要 求 在 reducer 中 保持 简单 ， 不 处 理 


= 


数据 。 我 们 会 在 connect 的 mapStateToProps 中 把 state 中 的 数据 做 一 些 转换 和 合并 ， 生 成 的 “ 衍 
生 数 据 ” 通 过 props 提供 给 组 件 。Redux 作者 把 这 个 产生 衍生 数据 的 方法 ， 称 为 selector。 


举 个 例子 ，state 中 有 一 份 radioGroup 的 数据 : 








{ 


result: 1， 
entities: { 


value: 2， 
name: 'B' 
} 
} 
} 


但 是 View 层 RadioGroup 组 件 接收 的 数据 格式 是 : 


[{ 
name: 'A', 
value: 1， 
selected: true 
}, { 
name: 'B', 
value: 2， 
selected: false 


}] 
这 里 引出 了 reactjs group 下 的 reselect 库 。 我 们 利用 reselect 在 connect 当中 对 radioGroup 做 
如 下 转换 : 


import { createSelector } from 'reselect'; 

















const getRadioGroup = (state) => state.radioGroup; 


const transformRadioGroup = createSelector( 
getRadioGroup, 
(radioGroup) => ({ 
radioGroupCompute: Object.keys(radioGroup.entities) 
.map(key => ({ 
.. .radioGroup[key], 
selected: key === String(radioGroup.result), 
})); 
])， 
); 
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@connect( 
transformRadioGroup, 
mapDispatchToProps 

) 


试想 一 下 ， 如 果 此 时 改变 了 store 中 radioGroup 以 外 的 任何 数据 ，connect 都 会 重新 计算 一 
次 transformRadioGroup 方法 ， 也 就 是 说 transformRadioGroup 方法 也 会 不 必要 地 重新 执行 。 


事实 上 ， 对 于 Redux 来 说 ， 每 当 store 发 生 改 变 时 ， 所 有 的 connect 都 会 重新 计算 。 在 一 个 
大 型 应 用 中 , 浪费 的 重复 计算 可 想 而 知 。 为 了 减少 性 能 浪费 ,我们 想到 对 connect 中 的 这 些 selector 
函数 做 缓存 。 

Redux 拥抱 了 也 数 式 编程 ， 而 在 函数 式 编程 中 ， 纯 函数 的 众多 好 处 之 一 就 是 方便 做 缓存 。 那 
么 ， 如 何 用 纯 函 数 做 缓存 呢 ? 

在 数学 上 ， 如 果 自 变量 不 变 ， 因 变量 总 是 不 变 。 同 样 ,， 用 相同 的 参数 执行 纯 函数 多 次 ， 每 次 
返回 的 结果 一 定 相 同 。 也 就 是 说 ， 如 果 纯 函数 的 参数 不 变 的 话 ， 可 以 把 之 前 用 同样 的 参数 计算 出 
来 的 结果 直接 返回 。 

幸运 的 是 ，reselect 库 中 已 经 自 带 了 缓存 特性 。 其 中 相关 的 实现 如 下 : 


export function defaultMemoize(func, equalityCheck = defaultEqualityCheck) { 
let lastArgs = null 
let lastResult = null 
return (...args) => { 
if ( 
LastArgs !== nuULL && 
lastArgs. length === args.Length && 
args.every((value, index) => equalityCheck(value, lastArgs[index])) 
){ 
return lastResult 
} 
lastResult = func(...args) 
lastArgs = args 
return lastResult 
} 
} 


defaultMemoize 闻 数 运用 了 闭 包 的 原理 ， 使 纯 也 数 的 参数 和 结果 缓存 在 内 存 中 。 为 了 让 
defaultMemoize 函数 中 缓存 的 数据 常 驻 内 存 ,， 我们 需要 让 defaultMemoize 处 于 全 局 作用 域 , 或 者 
用 其 他 作用 域 链 连 接 到 全 局 作用 域 。 

当 我 们 调用 createSelector 方法 时 ， 就 会 执行 createSelectorCreator(defaultMemoize) 
(...args)。 

抽象 selector， 我 们 就 不 会 因为 参数 的 改变 而 重 计算 衍生 数据 ， 而 且 selector 可 以 互相 组 合 ， 
提供 给 不 同 的 connect 使 用 ， 这 也 成 为 Redux 应 用 开发 中 必 不 可 少 的 约定 之 一 。 
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6.4.2 Immutable Redux 
我 们 在 5.6.7 节 中 展示 了 reducer 的 写法 ， 截 取 其 中 的 关键 片断 ， 如 下 : 


case LOAD_ARTICLES: { 
return { 

. .State, 
loading: true, 
error: false, 

}; 
} 


这 本 身 就 是 一 种 Immutable 的 写法 ， 我 们 在 书写 reducer 的 代码 时 ， 也 尽量 需要 按照 这 种 语 
法 去 写 。 如 果 层 级 很 深 的 话 ， 可 以 通过 自己 封装 函数 实现 ， 也 可 以 通过 updeep 库 来 做 。 比 如 : 


import u from 'updeep'; 























VA 
case LOAD ARTICLES: { 
return u({ 
title: { subTitle: 'react in action' }, 
loading: true, 
error: false, 
}, state); 





我 们 增加 一 个 藤 套 更 深 的 数据 结构 ， 那 么 在 引用 updeep 后 ， 数 据 就 具备 了 “不 可 变性 ”。 但 
不 幸 的 是 ， 在 Redux 中 ，combineReducers 方法 的 实现 使 用 的 是 纯 对 象 结构 ， 是 可 变 的 。 如 果 要 
彻底 使 用 不 可 变数 据 结构 去 做 整体 架构 的 话 ， 可 以 尝试 使 用 redux-immutable: 


import { combineReducers } from 'redux-immutable'; 
import { createStore } from 'redux'; 





























const initialState = Immutable.Map(); 
const rootReducer = combineReducers({}); 
const store = createStore(rootReducer, initialState); 


我 们 看 到 ， 只 是 combineReducers 引用 有 所 变化 。 如 果 整 体 使 用 Immutable.js， 也 不 失 为 一 个 
较 好 的 性 能 优化 点 。 




















6.4.3 Reducer 性 能 优化 

由 于 Redux 的 易 扩展 性 ， 我 们 可 以 轻易 封装 一 些 针对 reducer 的 性 能 优化 方法 ， 这 里 列举 几 
个 常用 的 方法 。 

1. LogSLowReducers 

说 到 性 能 优化 ， 我 们 必须 要 知道 在 分 发 action 过 程 中 哪 一 个 reducer 最 慢 ， 是 什么 原因 慢 。 
在 生产 环境 中 , 我 们 可 以 使 用 LogsLowReducers 函数 ,， 它 能 够 科 选 出 执行 时 间 较 高 的 reducer 以 及 
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对 应 的 action， 从 而 有 针对 性 地 做 优化 。 


那么 ， 怎 么 实现 它 呢 ? 众所周知 ，Redux 的 所 有 reducer 都 被 合并 到 一 个 reducer 上 。 因 此 ， 
我 们 可 以 轻易 对 reducer 进行 包装 来 打印 特定 的 reducer: 
export default function logSlowReducers(reducers, thresholdInMs = 8) { 


Object.keys(reducers).forEach((name) => { 
const reducer = reducers[name]; 





// 将 每 个 reducer 用 高 阶 函 数 包 装 

reducers[name] = (state, action) => { 
const start = Date.now(); 
const result = originalReducer(state, action); 
const diffInMs = Date.now() - start; 


if (diffInMs >= thresholdInMs) { 
console.warn( Reducer S${name} took S${diffInMs} ms for ${action.type}'); 
3 


return result; 
}; 
]); 
return reducers; 
} 
上 述 代 码 中 ， 我 们 记录 了 thresholdInMs 时 间 参 数 作为 边界 条 件 。 当 reducer 执行 时 间 超 过 
了 这 个 时 间 后 ， 就 会 在 浏览 需 中 报警 告 。 最 后 ， 可 以 很 方便 地 通过 分 析 工 具 记 录 下 结果 ， 然 后 一 
一 来 分 析 。 


2. specialActions 


在 Redux 中 ， 每 个 action 被 分 发 ， 所 有 的 reducer 都 会 被 执行 一 次 。 虽 然 每 个 reducer 仅仅 只 
是 执行 一 个 switch 判断 ， 但 所 有 的 reducer 加 起 来 的 执行 时 间 也 不 容 小 遍 。 

大 多 数 情况 下 ， 应 用 的 action 都 是 和 某 个 reducer 对 应 。 因 此 ， 我 们 可 以 指定 特殊 情况 ， 让 
Redux 在 特殊 情况 之 外 只 执行 与 action 对 应 的 那个 reducer。 例 如 : 















































const specialActions = (reducer, reg, actions) => { 
return (state, action) => { 
if (actions.indexOf(action.type) !== -1) { 
return reducer(state); 


} 


if (action.type.match(reg)) { 
return reducer(state); 


} 


return state; 
} 
} 


combineReducers({ 
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counter: specialActions(counter, /COUNTER$/, [SELECT_RADIO]), 
radio: specialActions(radio, /RADIOS$/, [INCREMENT_COUNTER]), 
]); 


但 像 这 样 的 优化 ， 建 议 你 放 到 最 后 ， 作 极致 优化 时 再 考虑 。 在 大 多 数 情况 下 , 我 们 最 需要 关 
注 的 是 几 个 最 大 的 性 能 瓶颈 。 

3. batchActions 

很 多 时 候 ， 我 们 需要 同步 分 发 很 多 独立 的 action， 例 如 : 


dispatch(action1); 
dispatch(action2); 
dispatch(action3); 


我 们 先 来 剖析 一 下 分 发 一 个 action 的 过 程 是 怎样 的 。 

首先 ，Redux 会 利用 reducer 更 新 当前 state， 然 后 执行 所 有 订阅 state 更 新 的 回调 ， 这 个 回调 
一 般 是 connect 中 的 mapToProps 方法 。 

因此 ， 分 发 是 一 个 较为 复杂 的 过 程 。 当 我 们 同步 分 发 多 个 action 时 ， 我 们 只 想 让 界面 泻 染 最 
终 的 状态 而 已 ， 这 个 过 程 产生 的 很 多 中 间 状 态 并 没有 必要 关心 。 那 么 ,能 否 按照 以 下 封装 把 这 几 


个 action 合并 呢 ? 





























dispatch(batchActions([action1, action2, action3])); 
答案 还 是 可 以 的 : 


const BATCH = 'BATCHED_ACTIONS ' ; 
const batchActions = actions => ({ type: BATCH, payload: actions }); 


const canBatchedReducer = reducer => { 
const batchedReducer = (state, action) => { 
if (action.type === BATCH) { 
return action.payload.reduce(batchedReducer, state); 


} 


return reducer(state, action); 
} 
} 
当然 , 我 们 还 可 以 通过 类 似 的 优化 点 来 优化 Redux 应 用 的 性 能 , 但 总 体 原则 一 定 是 减少 计算 
和 泻 梁 。 








6.5 解读 Redux 


讲 了 这 么 多 实战 的 内 容 , 我 们 相信 大 家 对 Redux 已 经 有 了 基本 的 认识 。 在 本 节 中 , 我 们 将 从 
源码 的 角度 深入 了 解 Redux 中 createStore 方法 的 具体 实现 ， 详 细 了 解 Redux 的 工作 原理 。 
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说 明 以 下 内 容 基 于 Redux 3.5.2 版 本 进行 。 


6.5.1 参数 归 一 化 


createStore 可 谓 是 整个 Redux 的 灵魂 。 基 本 上 ，Redux 的 核心 功能 已 经 全 部 被 吉 括 在 
createStore 及 createStore 方法 最 终生 成 的 store 中 。 下 面 让 我 们 了 解 一 下 createStore 究竟 是 
怎么 工作 的 。 

首先 ， 看 看 createStore 的 函数 签名 

export default function createStore(reducer, initialState, enhancer) { 


/ds 
} 


可 以 看 出 ， 它 接受 三 个 参数 : reducer 、initialState 和 enhancer 。 在 前 面 的 例子 中 ， 我们 已 
经 用 过 前 两 个 参数 进行 createStore 调用 。 那 么 ，enhancer 在 createStore 中 扮演 了 什么 角色 呢 ? 


事实 上 ，createStore 的 第 三 个 参数 是 在 Redux 3.1.0 之 后 才 加 入 的 。 下 面 我 们 看 看 它 究 竞 是 
如 何 工 作 的 : 


// createStore.js 第 30 行 起 

if (typeof initialState === 'function' && typeof enhancer === "undefined') { 
enhancer = initialState 
initialState = undefined 














} 
if (typeof enhancer !== 'undefined') { 
if (typeof enhancer !== 'function') { 
throw new Error('Expected the enhancer to be a function.') 
} 


return enhancer(createStore)(reducer, initialState) 


} 

从 上 述 代码 中 可 以 看 出 ，createstore 中 的 第 二 个 参数 不 仅 扮演 着 initialstate 的 角色 。 如 
果 我 们 传人 的 第 二 个 参数 是 函数 类 型 ,那么 createSstore 会 认为 你 忽略 了 initialstate 而 传人 了 
一 个 enhancer。 

如 果 我 们 传人 了 一 个 有 效 的 enhancer，createStore 会 返回 enhancer(createStore)(reducer， 
initialstate) 的 调用 结果 ， 这 是 常见 的 高 阶 函 数 调用 方法 。 在 这 个 调用 中 ，enhancer 接受 
createStore 作为 参数 ， 对 createSstore 的 能 力 进行 增强 ， 并 返回 增强 后 的 createStore。 然 后 再 
将 reducer 和 initialstate 作为 参数 传 给 增强 后 的 createStore， 最 终 得 到 生成 的 store。 


典型 使 用 案例 是 redux-devtools-extension ， 它 将 Redux DevTools 做 成 浏览 器 插件 。 
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6.5.2 ”初始 状态 及 getState 
在 完成 基本 的 参数 校 验 之 后 ， 在 createStore 中 声明 如 下 变量 及 getState 方法 : 


var currentReducer = reducer 
var currentState = initialState 
var listeners = [] 

var isDispatching = false 


/** 
* Reads the state tree managed by the store. 
* 


* @returns {any} The current state tree of your application. 
$y 
function getState() { 

return currentState 


} 

从 上 面 的 代码 中 可 以 看 到 ， 我 们 定义 了 4 个 本 地 变量 。 

口 currentReducer: 当前 的 reducer， 支 持 通过 store.replaceReducer 方式 动态 蔡 换 reducer， 
为 代码 热 蔡 换 提 供 了 可 能 。 

D currentState: 应 用 的 当前 状态 ， 默 认为 初始 化 时 的 状态 。 

口 listeners: 当前 监听 store 变化 的 监听 器 。 

口 isDispatching: 某 个 action 是 否 处 于 分 发 的 处 理 过 程 中 。 


而 getState 方法 用 于 返回 当前 状态 。 


























6.5.3 subscribe 
在 getState 之 后 ， 我 们 定义 了 store 的 男 一 个 方法 subscribe: 


function subscribe(listener) { 
listeners.push(listener) 
var isSubscribed = true 


return function unsubscribe() { 
if (!isSubscribed) { 
return 


} 


isSubscribed = false 
var index = listeners.indexOf(listener) 
listeners.splice(index, 1) 
} 
} 


你 可 能 会 感到 奇怪 ， 好 像 我 们 在 Redux 应 用 中 并 没有 使 用 store.subscribe 方法 ? 
React Redux 中 的 connect 方法 隐 式 地 帮 有 我 们 完成 了 这 个 工作 。 








上 
党 
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6.5.4 dispatch 


接 下 来 ， 要 说 到 的 就 是 store 非常 核心 的 一 个 方法 ， 也 是 我 们 在 应 用 中 经 常 直接 
( store.dispatch({ type: 'SOME_ACTION' }) ) 或 间接 (使 用 connect 将 action creator 与 dispatch 关 
联 ) 使 用 的 方法 
function dispatch(action) { 


if (!isplainObject(action)) { 
throw new Error( 


























dispatch: 


'Actions must be plain objects. ' + 
"Use custom middleware for async actions.' 
) 
} 
if (typeof action.type === 'undefined') { 


throw new Error( 
'Actions may not have an undefined "type" property. 
"Have you misspelled a constant? 
) 
3 


丰 


if (isDispatching) { 
throw new Error('Reducers may not dispatch actions.') 


: 


try { 

isDispatching = true 

currentState = currentReducer(currentState, action) 
} finally { 

isDispatching = false 


: 


listeners.slice().forEach(listener => listener()) 
return action 


} 
相 比 于 getState 和 subscribe,， dispatch 的 代码 稍 显 复杂 ， 下 面 我 们 逐 行 分 析 一 下 。 6 
首先 ， 我 们 校 验 了 action 是 否 为 一 个 原生 JavaScript 对 象 ， 若 不 是 ， 则 抛 出 错误 。 接 着 ,我 

们 校 验 了 action 对 象 是 否 包 含 type 字段 ， 这 段 检查 更 大 程度 上 是 为 了 帮助 粗心 的 开发 者 发 现 拼 

错 type 常数 的 情况 。 
接 下 来 判断 当前 是 否 处 于 某 个 action 的 分 发 过 程 中 ， 这 个 检查 主要 是 为 了 避免 在 reducer 中 

分 发 action 的 情况 ， 因 为 这 样 做 可 能 导致 分 发 死 循 环 ， 同 时 也 增加 了 数据 流动 的 复杂 度 。 
确认 当前 不 属于 分 发 过 程 中 后 ， 先 设 定 标志 位 ， 然 后 将 当前 的 状态 和 action 传 给 当前 的 

reducer， 用 于 生成 最 新 的 state。 这 看 起 来 一 点 都 不 复杂 ， 这 也 是 我 们 反复 强调 的 reducer 工作 过 

程 一 一 纯 函 数 、 接 受 状 态 和 action 作为 参数 ， 返 回 一 个 新 的 状态 。 


在 得 到 新 的 状态 后 ， 依 次 调用 所 有 的 监听 器 ,通知 状态 的 变更 。 需 要 注意 的 是 ,我 们 在 通知 
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监听 器 变更 发 生 时 , 并 没有 将 最 新 的 状态 作为 参数 传递 给 这 些 监 听 器 。 这 是 因为 在 监听 器 中 , 我 
们 可 以 直接 调用 store.getstate() 方法 拿 到 最 新 的 状态 。 


最 终 ， 人 处理 之 后 的 action 会 被 dispatch 方法 返回 。 








6.5.5 replaceReducer 
这 个 方法 主要 用 于 reducer 的 热 奉 换 ， 在 开发 过 程 中 我 们 一 般 不 会 直接 使 用 这 个 API;: 


function repLaceReducer(nextReducer ) { 
currentReducer = nextReducer 
dispatch({ type: ActionTypes.INIT }) 
} 


完成 上 述 方法 的 声明 后 ， 我 们 分 发 了 Redux 应 用 的 第 一 个 action: 

dispatch({ type: ActionTypes.INIT }) 

这 是 为 了 拿 到 所 有 reducer 中 的 初始 状态 (你 是 否 还 记得 在 定义 reducer 时 ， 第 一 个 参数 为 
previousState， 如 果 该 参数 为 空 ， 我 们 提供 默认 的 initialstate )。 只 有 所 有 的 初始 状态 都 成 功 
获取 后 ，Redux 应 用 才能 有 条 不 名 地 开始 运作 。 

现在 我 们 对 Redux 的 实现 原理 有 了 一 个 完整 的 认识 。 相 比 Flux，Redux 的 设计 有 非常 多 值得 
推 项 的 地 方 ， 我 们 也 因此 领略 了 不 同 编程 思想 碰撞 的 火花 。Redux 本 身 是 一 个 通用 思想 ， 现 在 已 
经 有 其 他 框架 对 Redux 进行 变化 使 用 的 案例 ， 如 Vuex 等 。 










































































6.6 解读 react-redux 


在 发 布 1.0.0 正式 版 之 前 ，Redux 的 代码 库 中 不 仅 有 Redux 本 身 的 实现 , 还 有 许多 跟 React 相 
关 的 方法 。 然 而 从 1.0.0 起 ， 所 有 与 React 有 关 的 实现 全 部 被 转移 到 了 男 一 个 库 react-redux 中 。 

顾名思义 ，react-redux 为 我 们 提供 了 React 与 Redux 之 间 的 绑 定 ， 也 就 是 我 们 在 例子 中 使 用 
的 Provider 和 connect 方法 。 在 本 节 中 ， 我 们 将 从 源 代码 层面 详细 解读 react-redux 的 设计 思路 以 
及 实现 原理 。 








说 明 ”以 下 分 析 基 于 react-redux(@4.4.5 版 本 的 API 进行 。 


6.6.1 Provider 


在 我 们 的 例子 中 ，Provider 是 整个 应 用 最 外 层 的 React 组 件 ， 它 接受 一 个 store 作为 props。 
除 此 之 外 ,似乎 没有 什么 特别 之 处 。 那 么 ，Provider 拿 到 这 个 store 做 了 什么 处 理 呢 ? 让 我 们 看 看 
Provider 的 源码 : 
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export default class Provider extends Component { 
getChildContext() { 
return { store: this.store } 


constructor(props, context) { 
super(props, context) 
this.store = props.store 


render() { 
const { children } = this.props 
return Children.only(children) 


} 
} 


以 上 是 react-redux 中 Provider 的 部 分 源 代码 。 可 以 看 到 ， 其 实 Provider 的 实现 非常 简单 。 在 
constructor 中 , 拿 到 props 中 的 store, 并 挂 载 在 当前 实例 上 。 同 时 定义 了 getchildcontext 方法， 
该 方法 定义 了 自动 沿 组 件 传递 的 特殊 props。 

除了 context，Provider 的 源 代码 中 还 有 如 下 几 行 特殊 的 定义 : 




















if (process.env.NODE_ENV !== 'production') { 
Provider .prototype.componentWillReceiveProps = function (nextProps) { 
const { store } = this 
const { store: nextStore } = nextProps 


if (store !== nextStore) { 
warnAboutReceivingStore() 
} 
} 
} 


熟悉 Node 的 读者 ， 就 会 知道 process 是 Node 应 用 自 带 的 一 个 全 局 变量 ,可 以 获取 当前 进程 
的 奉 干 信息 。 而 在 许多 前 端 库 中 ,经 常会 使 用 process .env.NODE_ENV 这 个 环境 变量 来 判断 当前 是 
在 开发 环境 还 是 生产 环境 中 。 

从 上 面 的 定义 可 以 看 出 ， 如 果 当 前 不 是 生产 环境 ，Provider 中 额外 定义 了 一 个 
componentWillReceiveProps 的 生命 周期 。 在 这 个 生命 周期 中 ， 如 果 发 现 props 中 的 store 发 生 了 


变化 ， 则 执行 warnAboutReceivingStore: 






































let didWarnAboutReceivingStore = false 
function warnAboutReceivingStore() { 
if (didWarnAboutReceivingStore) { 
return 


} 


didWarnAboutReceivingStore = true 


warning( 
"<Provider> does not support changing “store. on the fly. 
'It is most likely that you see this error because you updated to 


汪 


+ 
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"Redux 2.x and React Redux 2.x Which no Longer hot reload reducers ' + 
"automaticaLLy. See https://github.com/reactjs/react-redux/releases/' + 
"tag/v2.0.0 for the migration instructions.' 


) 
} 


实际 上 ，warnAboutReceivingStore 是 一 个 为 了 方便 开发 者 升级 的 警示 方法 ， 并 没有 任何 实 
际 的 作用 。 





6.6.2 connect 


相 比 于 Provider，connect 的 实现 就 复杂 得 多 ， 毕 况 connect 这 个 函数 接受 的 参数 多 达 4 个 ， 
每 个 参数 又 有 若干 种 可 选 形 式 。 若 想 了 解 connect 的 作用 和 原理 , 还 需要 一 步 一 步 理 清 connect 的 
具体 实现 。 

首先 ， 让 我 们 看 看 connect 函数 的 代码 结构 : 


import hoistStatics from 'hoist-non-react-statics’ 








export default function connect(mapStateToprops, mapDispatchToprops, mergeProps, options = {}) { 
[vis 
return function wrapWithConnect(WrappedComponent) { 
Fie 
class Connect extends Component { 
人 
render() { 


Fa 
if (withRef) { 
this.renderedElement = createElement(WrappedComponent, { 
.. .this.mergedProps, 
ref: "wrappedInstance' 
}) 
} else{ 
this.renderedElement = createElement(WrappedComponent, 
this.mergedProps 
) 
} 


return this.renderedElement 


} 
} 
[as 


return hoistStatcis(Connect, WrappedComponent); 


} 
} 


可 以 看 出 ，connect 函数 本 身 返 回 名 为 wrapWithConnect 的 函数 ， 而 这 个 函数 才 是 真正 用 来 
装饰 React 组 件 的 。 而 在 我 们 装饰 一 个 React 组 件 时 ， 其 实 就 是 把 组 件 在 Connect 类 的 render 方 
法 中 进行 泻 染 ， 并 获取 connect 中 传人 的 各 种 额外 数据 。 
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接 下 来 ， 让 我 们 依次 对 connect 子 数 的 4 个 参数 做 深度 了 解 。 

1. mapStateToProps 

connect 的 第 一 个 参数 定义 了 我 们 需要 从 Redux 状态 树 中 提取 哪些 部 分 当 作 props 传 给 当前 
组 件 。 一 般 来 说 ， 这 也 是 我 们 使 用 connect 时 经 常 传人 的 参数 。 事 实 上 ， 如 果 不 传人 这 个 参数 ， 
React 组 件 将 永远 不 会 和 Redux 的 状态 树 产 生 任何 关系 。 具 体 在 源 代码 中 的 表现 为 : 




















export default function connect(mapStateToprops, mapDispatchTopProps, mergeProps, options = {}) { 
const shouldSubscribe = Boolean(mapStateToProps) 
a 
class Connect extends Component { 
WA 
trySubscribe() { 
if (shouldSubscribe && !this.unsubscribe) { 
this.unsubscribe = this.store.subscribe(this.handleChange.bind(this)) 
this.handleChange() 











因此 , 如 果 尝 试 使 用 connect 让 组 件 与 Redux 状态 树 产 生 关 联 , 第 一 个 参数 mapStat eToProps 
可 以 说 是 必 传 的 。 

那么 ， 我 们 传人 的 mapStateToProps 是 怎么 生效 的 呢 ? 看 看 Connect 类 中 定义 的 configure 
FinalMapState 方法 就 能 略 知 一 二 : 


const mapState = mapStateToProps || defauLtMapStateToProps 
A 
class Connect extends Component { 
configureFinalMapState(store, props) { 
const mappedState = mapState(store.getState(), props) 
const isFactory = typeof mappedState === 'function' 




















this.finalMapStateToProps = isFactory ? mappedState : mapState 
this.doStatePropsDependOnOwnProps = this.finalMapStateToProps.length !== 1 


if (isFactory) { 
return this.computeStateProps(store，props) 


} 

if (process.env.NODE_ENV !== 'production') { 
checkStateShape(mappedState, 'mapStateToprops') 

} 

return mappedState 


3 


ComputeStateProps(store，props) { 
if (!this.finalMapStateToProps) { 
return this.configureFinalMapState(store, props) 
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} 


const state = store.getState() 

const stateProps = this.doStatepropsDependOnOwnProps ? 
this.finalMapStateToprops(state, props) : 
this.finaLMapStateToProps(state) 


if (process.env.NODE_ENV !== 'production') { 
checkStateShape(stateProps, 'mapStateToProps') 
return stateProps 
} 


} 


首先 ,我 们 对 connect 中 传人 的 mapStateToProps 参数 做 了 默认 参数 校 验 ， 若 没有 传 入 ， 则 使 
用 defaultMapStateToProps。defaultMapStateToProps 只 是 一 个 返回 空 对 象 的 方法 而 已 。 


在 最 终 演 染 被 connect 装饰 过 的 组 件 时 ， 会 调用 this.computestateProps 计算 出 最 终 从 
Redux 状态 树 中 提取 出 了 哪些 值 作为 当前 组 件 的 props。 

而 在 计算 之 前 ， 又 会 校 验 当 前 组 件 是 否 有 定义 finalMapStateToProps ， 若 没有 ， 则 返回 
this.configureFinalMapState 的 调用 结果 。 那 么 configureFinalMapState 里 又 做 了 什么 处 理 呢 ? 


首先 , 将 当前 的 store 和 props 作为 参数 传 给 mapstate， 得 到 执行 的 结果 。 ee 
档 中 的 说 明 ， 一般 情况 下 ， 传 给 connect 的 mapStateToProps 国 数 必须 返回 一 个 对 象 。 但 是 在 
些 特殊 情况 下 ， 比 如 需要 针对 个 别 组 件 进行 极致 优化 的 时 候 ，mapStateToProps 也 可 以 返 一 个 
函数 。 这 也 是 为 什么 在 源 代 码 中 需要 判断 返回 的 值 是 否 为 函数 。 


接 下 来 ， 如 果 mapstate 返回 的 是 函数 ， 那 么 当前 组 件 最 终 的 mapStateToProps 方法 就 是 我 们 
传人 的 第 一 个 参数 执行 后 返回 的 那个 函数 ， 否 则 就 还 是 原先 定义 的 mapState 函数 。 

我 们 可 能 会 疑惑 为 什么 传 给 connect 的 第 一 个 参数 本 身 是 一 个 函数 ，react-redux 还 允许 这 

函数 的 返回 值 也 是 一 个 函数 呢 ? 

简单 地 说 ， 这 样 设计 可 以 允许 我 们 在 connect 的 第 一 个 参数 里 利用 陶 数 闭 包 进行 一 些 复杂 计 
算 的 缓存 ， 从 而 实现 效率 优化 的 目的 。 更 多 关于 这 方面 优化 的 内 容 ， 可 以 在 6.4 节 中 了 解 到 。 

2. mapDispatchToProps 

说 完了 mapStateToProps， 让 我 们 来 看 看 mapDispatchToProps 方法 ， 这 也 是 connect 方法 接 
受 的 第 二 个 参数 。 它 接受 store 的 dispatch 作为 第 一 个 参数 ， 同 时 接受 this .props 作为 可 选 的 第 
二 个 参数 。 利 用 这 个 方法 ， 我 们 可 以 在 connect 中 方便 地 将 actionCreator 与 dispatch 绑 定 在 一 起 
(利用 bindActionCreators 方法 ) ， 最 终 绑 定 好 的 方法 也 会 作为 props 传 给 当前 组 件 。 


具体 设计 上 与 mapStateToProps 的 思路 基本 一 致 ， 除 了 mapDispatchToProps 接受 的 第 一 个 参 
数 是 store.dispatch 而 不 是 store.getState()。 

























































































6.6 解读 react-redux 293 





3. mergeProps 


根据 文档 中 的 定义 ，mergeProps 参数 也 是 一 个 函数 ， 接 受 stateProps、dispatchProps 和 
ownProps 作为 参数 ,实际 上 ，stateProps 就 是 我 们 传 给 connect 的 第 一 个 参数 mapStateTopProps 最 
终 返 回 的 props。 同 理 ，dispatchProps 是 第 二 个 参数 的 最 终 产 物 ， 而 ownProps 则 是 组 件 自己 的 
props。 这 个 方法 更 大 程度 上 只 是 为 了 方便 对 三 种 来 源 的 props 进行 更 好 的 分 类 、 命 名 和 重组 。 


4. options 
connect 参数 接受 的 最 后 一 个 参数 是 options， 其 中 包含 了 两 个 配置 项 。 


口 pure: 布 尔 值 ,默认 为 true。 当 该 配置 为 true 时 ,Connect 中 会 定义 shouLdComponentUpdate 
方法 并 使 用 浅 对 比 判 断 前 后 两 次 props 是 否 发 生 了 变化 ， 以 此 来 减少 不 必要 的 刷新 。 如 果 
应 用 严格 按照 Redux 的 方式 进行 架构 ， 该 配置 保持 默认 即 可 。 

口 withRef: 布尔 值 ， 默 认为 false。 如 果 设 置 为 true, 在 装饰 传人 的 React 组件 时 ，Connect 
会 保存 一 个 对 该 组 件 的 refs 引用 ， 你 可 以 通过 getWrappedInstance 方法 来 获得 该 refs， 
并 最 终 获得 原始 的 DOM 节点 。 






















































































6.6.3 代码 热 蔡 换 


很 多 第 一 次 接触 Redux 的 开发 者 都 是 被 它 的 代码 热 蔡 换 功 能 吸引 住 的 眼球 ,不 少 人 知道 实现 
热 替 换 是 Redux 的 store 提供 了 replaceReducer 的 功能 支持 。 事 实 上 ， 如 果 不 是 react-redux 中 的 
connect 方 法 也 添加 了 相关 的 支持 ,代码 热 蔡 换 功 能 不 可 能 在 Redux 应 用 中 那么 轻而易举 地 实现 : 



































if (process.env.NODE_ENV !== 'production') { 
Connect.prototype.componentWillUpdate = function componentWillUpdate() { 
if (this.version === version) { 
return 
} 


this.version = version 
this.trySubscribe() 
this.clearCache() 
} 
} 
代码 热 蔡 换 功 能 肯定 发 生 在 应 用 开发 过 程 中 , 因此 首先 最 外 层 有 一 个 对 当前 环境 的 判断 。 若 
在 开发 环境 ， 则 为 connect 额外 定义 一 个 componentWtLLUpdate 的 生命 周期 方法 ， 判 断 当 前 组 件 
的 version 是 否 与 全 局 的 version 不 同 ， 若 不 同 ， 则 更 新 version 并 重新 执行 订阅 等 操作 。 


那么 ， 这 个 version 是 如 何 定义 的 呢 ? 让 我 们 再 次 回 到 connect 的 源 代码 中 寻找 答案 : 


// 帮助 追踪 热 重 载 
let nextVersion = 0 
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export default function connect(mapStateToProps，mapDispatchToProps，mergeProps，options = {}) { 
Va AE 
// 帮助 追踪 热 重 载 


const version = nextVersion++ 


return function wrapWithConnect(WrappedComponent) { 


A 
class Connect extends Component { 
constructor(props, context) { 


7 


this.version = version; 
} 
} 
} 

} 

在 每 次 connect 执行 的 时 候 ，nextVersion 都 会 加 1， 而 version 则 被 赋 为 当前 的 版 本 号 。 同 
时 在 Connect 类 初始 化 进行 构造 时 , 会 将 全 局 的 version 设 为 自己 实例 的 version。 这 样 ,connect 
下 次 执行 的 时 候 ，version 发 生 了 变化 ， 因 而 在 额外 定义 的 componentWtLLUpdate 中 ， 当 前 示例 的 
version 与 全 局 version 不 相同 ， 最 终 触发 了 Redux 的 重新 订阅 及 缓存 清空 。 


需要 额外 说 明 的 是 ， 为 了 让 使 用 connect 与 Redux 进行 绑 定 的 组 件 能 够 尽 可 能 避免 不 必要 的 
更 新 ，connect 中 还 定义 了 一 系列 的 判断 当前 组 件 是 否 需 要 更 新 的 逻辑 。 这 些 逻 辑 主 要 是 根据 当 
前 的 配置 进行 state 的 前 后 对 比 ， 可 以 想象 成 一 个 建议 的 shouldComponentUpdate 实现 。 






































6.7 ”小结 














本 章 继续 从 Redux 的 各 方面 深入 讲述 其 实际 应 用 , 其 中 很 多 内 容 来 自 于 经 验 , 可 能 并 不 是 最 
佳 实践 ， 因 此 这 些 内 容 只 是 抛砖引玉 ， 怎 样 实践 才 是 最 佳 实践 仍 待 读者 去 探索 。 
前 端 应 用 架构 在 这 个 时 代 下 高 速 发 展 , 现在 业界 对 Redux 有 些 过 度 宣传 , 其 实 并 不 是 所 有 应 


用 都 需要 “最 佳 实践 ”里 的 全 家 桶 。 我 们 需要 有 更 宽广 的 视野 去 看 待 不 同 的 解决 方案 , 比如 RxJS、 
MobX 、Cerebral 等 。 


Redux 作者 Dan Abramov 认为 ,未 来 Redux 只 是 一 个 更 大 的 架构 中 的 一 个 环节 。 这 个 更 大 的 


架构 被 称 为 Inmutable App Architecture 架构 , 它 试图 去 解决 更 多 的 问题 , 诸如 描述 性 的 数据 获取 、 
易于 测试 的 异步 流 、 优 化 开发 者 体验 等 


















































众所周知 ， 在 目前 的 Web 应 用 中 ， 各 种 交互 操作 变 得 越 来 越 丰 富 ， 对 用 户 体 验 的 要 求 也 越 
来 越 高 。 这 几 年 , Nodejs 引领 了 前 后 端 分 层 的 浪潮 ， 而 React 的 出 现 让 分 层 思想 可 以 更 加 彻底 地 
执行 ， 尤 其 是 React 同 构 的 出 现 。 这 个 黑 科 技 到 底 是 如 何 实现 的 ， 本 章 就 来 一 探究 竞 。 



































7.1 React 与 服务 端 模板 


进入 富 客户 端 时 代 后 ,早期 流行 的 架构 都 存在 一 个 通病 , 那 就 是 首 屏 加 载 的 白 屏 问题 ， 即 模 
板 内 容 空 ， 所 有 的 交互 及 数据 请 求 逻 辑 都 需要 在 客户 端 加 载 并 执行 JavaScript 后 才 完 成 对 内 容 的 
填充 。 这 一 问题 对 于 应 用 的 用 户 体验 来 说 是 一 个 极 大 的 损害 ， 针 对 这 个 问题 ，React 给 出 了 自己 
的 解决 方案 ， 那 就 是 服务 端 泻 染 。 









































7.1.1 什么 是 服务 端 泻 染 


服务 端 演 染 ， 意 味 着 前 端 代码 可 以 在 服务 端 作 泻 染 ， 进 而 达到 在 同步 请 求 HTML 时 ， 直 接 
返回 浑 染 好 的 页 面 。 这 样 做 的 好 处 主要 有 以 下 3 点 。 

口 利于 SEO。 服 务 端 渔 染 可 以 让 搜索 引擎 更 容易 读 取 页 面 的 meta 信息 以 及 其 他 SEO 的 相 

关 信息 ， 大 大 增加 了 网 站 在 搜索 引擎 中 的 可 见 度 。 

口 加 速 首 屏 渲染 。 客 户 端 浑 染 的 一 个 缺点 是 ， 当 用 户 第 一 次 进入 站 点 时 ， 因 为 此 时 浏览 
中 没有 缓存 ， 需 要 下 载 代码 后 在 本 地 泻 染 ， 时 间 较 长 。 而 服务 端 泻 染 则 是 ， 用 户 在 下 载 
时 已 经 是 泻 染 好 的 页 面 了 ， 其 打开 速度 比 本 地 泻 染 快 。 

口 服务 端 和 客户 端 可 以 共享 某 些 代码 ， 避 免 重复 定义 。 这 样 可 以 使 结构 更 清晰 ， 增 加 可 维 

护 性 。 

React 之 所 以 能 做 到 服务 端 泻 染 ， 主 要 是 因为 ReactDOM。 我 们 对 ReactDOM. render 方法 并 不 
陌生 ， 这 是 React 泻 染 到 DOM 中 的 方法 。 在 ReactDOM 中 ， 还 有 一 个 分 文 reactrdom/server， 它 
可 以 让 React 组件 以 字符 串 的 形式 泻 染 。 

React 官方 给 我 们 提供 服务 端 泻 染 的 API 




































































renderToString 和 renderToStaticMarkup, 它们 
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都 是 react-dom/server 内 的 方法 。 它 们 与 render 的 区 别 是 render 方法 需要 指定 具体 泻 染 到 DOM 
上 的 节点 , 但 这 两 个 方法 都 只 返回 了 一 段 HTML 字符 串 。 这 就 是 让 React 成 为 模板 语言 的 充分 条 
件 。 而 这 两 个 方法 的 区 别 如 下 。 
口 React.renderToString: 它 把 React 元 素 转 成 一 个 HIML 字符 串 并 在 服务 端 标识 reactid。 
所 以 在 浏览 器 端 再 次 浑 梁 时 ，React 只 是 做 事件 绑 定 等 前 端 相 关 的 操作 ， 而 不 会 重新 泻 染 
整个 DOM 树 , 这 样 能 带 来 高 性 能 的 页 面 首次 加 载 。“ 同 构 ” 黑 魔法 主要 就 是 从 这 个 API 而 
来 的 。 
口 React.renderToStaticMarkup: 它 相 当 于 简化 版 的 renderToString。 如 果 应 用 基本 上 是 静 
态 文本 ， 建 议 用 这 个 方法 。 少 了 大 批 的 reactid，DOM 自然 精简 了 不 少 , 在 IO 流传 输 上 
也 节省 了 流量 。 
配合 renderToString 和 renderToStaticMarkup 这 两 个 方法 使 用 ，React.createELement 将 返 
回 的 ReactELement 作为 参数 传递 给 前 面 两 个 方法 。 
























































7.1.2 react-view 

要 做 到 在 服务 端 泻 染 ， 我 们 还 需要 做 一 些 准备 工作 。 

每 一 个 B/S 架构 的 框架 都 会 涉及 View 层 的 展现 ，Koa 也 不 例外 。 我 们 在 做 View 层 模板 引擎 
的 时 候 ， 一般 有 两 种 做 法 : 一 种 是 做 成 搬 件 的 形式 ， 另 一 种 是 做 成 middleware 的 形式 。 

再 说 回 React， 常 常 有 人 说 它 是 增强 版 的 模板 引擎 。 从 表象 来 看 ， 它 的 确 是 。React 可 以 替换 
变量 , 有 条 件 判 断 , 有 循环 判断 , 其 JSX 语法 让 演 染 过 程 与 HTML 没什么 两 样 。 毕 竟 说 到 底 React 
就 是 JavaScript， 而 React 所 推崇 的 无 状态 函数 ， 彻 彻底 底 地 把 React 变 成 了 像 是 模板 的 样子 。 

从 内 在 来 看 ，React 还 是 JavaScript， 可 以 方便 地 做 模块 化 管理 ， 有 内 部 状态 ， 有 自己 的 数据 
流 。 它 可 以 做 一 部 分 Controller， 或 者 说 ， 可 以 完全 承担 Controller 的 工作 。 


但 是 在 服务 端 ， 使 用 模板 是 为 了 做 浏览 器 同步 HTML 的 请 求 。 因 此 ， 简 单 地 说 ， 同 步 页 面 
的 请 求 只 需要 有 泻 染 HTML 文本 的 功能 就 行 了 。 


事实 上 ，Koa 官方 已 经 为 我 们 实现 了 react-view 这 个 插件 。 下 面 通过 进一步 解读 它 的 代码 来 
学 习 React 怎么 参与 到 View 的 泻 染 ， 以 及 怎么 实现 Node View 引擎 react-view。 






























































7.1.3 react-view 源码 解读 
对 于 react-view 的 源码 ， 我 们 主要 从 配置 、 演 染 、cache 和 Babel 这 4 个 方面 来 讲解 。 
1. 配置 
配置 是 设计 的 源头 之 一 ， 一 切 源码 都 可 以 从 配置 开始 研究 : 


var defaultOptions = { 
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doctype: '<!DOCTYPE htmL> ' ， 
beautify: false, 
cache: process.env.NODE_ENV === 'production', 
extname: 'jsx', 
writeResp: true, 
views: path.join(__dirname, 'views'), 
internals: false 
}; 
观察 上 述 配 置 ， 会 发 现 有 handlebars 或 是 jade View 有 相似 之 处 。 我 们 看 到 react-view 的 配置 
与 其 他 View 的 配置 有 些 是 相同 的 ， 有 些 又 是 不 同 的 。 比 如 doctype 、internals 这 些 配置 都 是 其 


他 模板 引擎 不 会 有 的 。 
那么 ， 模 板 常用 的 配置 应 该 是 什么 呢 ? 


口 viewPath : 在 上 述 配 置 代码 中 ,用 的 是 vitews， 其 含义 都 是 相同 的 ， 就 是 配置 View 的 目 
录 。 这 是 每 一 个 模板 plugin 或 middleware 都 需要 去 配 的 路 径 信息 。 

口 extname: 表示 后 级 名 是 什么 。 一般 来 说 , 模板 引擎 都 有 自己 独 有 的 后 级 ， 当 然 不 排除 可 
以 有 喜好 选择 的 情况 。 比 如 对 于 React 而 言 ， 就 可 以 写成 是 .jsx 或 js 两 种 不 同 的 形式 。 
D cache: 我 想 一 般 模 板 引擎 都 会 带 缓存 功能 ， 因 为 模板 的 解析 是 需要 耗费 资源 的 ， 而 模板 
本 身 的 改动 频 度 是 非常 低 的 。 每 当 发 布 的 时 候 ， 我 们 去 刷新 一 次 模板 即 可 。 


2. 泻 染 


标准 的 泻 染 过 程 其 实 非常 简单 。 对 于 React 来 说 ， 就 是 读 取 目 录 下 的 文件 ， 就 像 前 端 加 载 一 
样 使 用 requtre。 最 后 ， 利 用 ReactpoMserver 中 的 方法 来 演 染 : 




























































































var render = internals 
? ReactDOMServer .renderToString 
: ReactDOMServer.renderToStaticMarkup; 


var markup = options.doctype || ''; 

try { 

var component = require(filepath); 

// 转换 ES6 代码 后 ， 组 件 输 出 可 能 是 形 如 { defauLt: Component } 的 形式 
component = component.default || component; 

markup += render(React.createElement(component, locals)); 

catch (err) { 

err.code = 'REACT'; 

throw err; 


} 


Dd 





if (options.beautify) { 
// 注意 : 它 可 能 会 弄 错 一 些 重 要 的 空格 ， 而且 和 生产 环境 下 有 所 不 同 
markup = beautifyHTML(markup); 

} 


var writeResp = locals.writeResp === false 
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? false 
: (locals.writeResp || options.writeResp); 


if (writeResp) { 
this.type = 'html'; 
this.body = markup; 
} 


return markup 

这 里 我 们 截取 最 关键 的 片段 。 正 如 我 们 预 估 的 演 染 过 程 一 样 。 但 我 们 看 到 ， 从 流程 上 看 有 4 
个 细节 。 

(1) 设置 doctype 的 目的 

在 一 般 模 板 中 ， 我 们 很 少 看 到 将 doctype 放 在 配置 中 配置 ,但 因为 React 的 特殊 性 ， 我 们 不 
得 不 这 么 做 。 原 因 很 简单 ，render 方法 返回 时 ， 一定 需要 一 个 包 庄 的 标签 ， 比 如 <div>、<ul>， 
甚至 是 <htmL>。 因 此 ， 我 们 需要 手动 去 加 <doctype> 标签 。 

(2) 泻 染 React 组 件 

这 里 就 是 我 们 刚才 提 到 的 两 个 关键 API。 在 render 方法 里 , 我 们 看 到 了 React .createELement 
方法 。 因 为 在 服务 端 render 方法 没有 Babel 编译 ， 所 以 写 的 其 实 是 <component {...locals} /> 编 
译 后 的 代码 。 

(3) 美化 HTML 

options .beautify 配置 了 我 们 是 否 要 美化 HTML， 上 默认 情况 下 这 是 关闭 的 。 任 何 需 要 编译 的 
模板 引擎 一 般 都 会 有 类 似 的 配置 。 在 React 中 ， 因 为 render 后 的 代码 是 未 格式 化 的 单行 字符 串 ， 
所 以 返回 到 前 台 时 都 是 无 法 阅读 的 代码 。 在 必要 时 ， 我 们 可 以 开启 这 个 配置 。 

(4) 绑 定 到 上 下 文 

最 后 一 步 ， 尽 管 有 一 个 开关 控制 ， 但 我 们 看 到 最 后 是 把 内 容 绑 定 到 this.body 下 的 。 这 里 省 
略 了 一 部 分 代码 , 最 终 实现 react-view 其 实 是 重 载 了 app.context.render 方法 。 如 果 app.context . 
render 方法 是 function* 的 话 ， 那 么 我 们 的 react-view 就 会 变 为 middleware。 
































































































































3. cache 
我 们 从 一 开始 就 看 到 了 配置 中 有 cache 配置 ,但 是 这 个 cache 是 不 是 我 们 所 想 的 呢 ? 这 里 来 
看 一 下 源 代码 : 


// 匹配 模板 文件 路 径 以 清除 cache 
var match = createMatchFunction(options.views); 











if (!options.cache) { 
cleanCache(match); 


} 
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这 里 的 cleanCache 自然 指 的 是 缓存 清除 的 方法 : 


function cleanCache(match) { 
Object.keys(require.cache).forEach(function(module) { 
if (match(require.cache[modulel].filename)) { 
delete require.cache[module]; 
} 
}); 

} 

为 什么 这 么 做 呢 ? 因为 我 们 读 取 React 文件 用 的 是 require 方 法， 而 不 是 readFile 方法。 而 
在 Node.js 中 ，require 本 身 就 带 有 缓存 机 制 ，Nodejjs 在 第 一 次 加 载 其 个 模块 时 就 会 将 该 模块 组 
存 ， 存 人 全 局 的 -cache 中 。 在 一 般 情况 下 ， 我 们 都 需要 这 人 么 做 。 

在 传统 模板 引擎 中 ,缓存 机 制 一 般 设置 在 文件 读 取 处 , 主要 作用 是 将 磁盘 存储 转 为 内 存 存储 。 
而 在 react-view 中 ， 使 用 的 模板 即 是 JavaScript 文件 ， 所 以 使 用 require 本 身 就 不 用 再 加 入 额外 
的 缓存 机 制 了 。 

值得 关注 的 是 ， 如 果 delete require.cache 出 现在 服务 端 代码 中 ， 是 极 易 出 现 内 存 泄漏 的 。 

4. Babe 

我 想 很 多 开发 者 在 写 React 组 件 时 用 的 是 ES6 class， 而 且 会 用 到 很 多 ES6/ES7 的 方法 ,不 巧 
的 是 Node.js 还 不 支持 其 中 的 某 些 高 级 特性 。 因 此 ， 就 引 到 了 一 个 话题 ， 服 务 端 如 何 引 用 Babel? 

在 业务 中 有 babel-node 这 类 解决 方案 ,但 这 上 毕竟 是 一 个 实验 性 的 Node.js， 我 们 不 能 拿 到 生 
产 环境 去 冒险 。 


在 koa/react-view middleware 内 ， 有 一 段 说 明 , 它 建 议 开发 者 在 使 用 的 时 候 加 入 babel-register 
作 实 时 编译 。 关 于 这 个 问题 ,当然 也 可 以 写 在 middleware 内 , 在 加 载 模板 前 引入 。 但 Koa View 不 
在 内 部 实现 ， 我 相信 是 因为 Babel 不 论 是 否 引用 ， 都 需要 在 被 使 用 的 项 目 中 重新 引用 这 一 问题 。 

其 实 ， 实 现 View 非常 简单 ， 我 们 也 从 一 些 维度 看 到 了 设计 一 个 View 的 一 般 方 法 。 在 具体 
实现 的 时 候 ， 我 们 可 以 用 一 些 更 好 的 方法 去 做 ， 比 如 用 类 来 抽象 View， 用 promise 来 描述 过 程 。 
这 些 留待 读者 自己 去 优化 。 
最 后 ， 推 荐 Airbnb 公司 推出 的 hypernova 综合 解决 方案 ， 它 除了 支持 Node.js 以 外 ， 还 支持 
Ruby 等 语言 。 可 以 说 ， 它 是 业界 备 受 关注 的 服务 端 泻 染 解 决 方案 。 























































































































7.2” React 服务 端 泻 染 


在 7.1 节 中 , 我 们 学 习 了 React 在 服务 端 泻 染 的 基础 理论 , 即 ReactDoMSserver 提供 的 两 个 API 
以 及 服务 端 实现 的 View 搬 件 。 在 本 节 中 ， 我 们 就 以 一 个 具体 的 例子 展开 ， 来 看 如 何 用 React 做 
服务 端 泻 染 。 
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7.2.1 玩 转 Node.js 


演 染 端 演 染 的 基础 不 仅 在 于 API， 还 在 于 我 们 使 用 的 是 Node.js。 下 面 使 用 Koa 这 个 服务 端 
框架 来 做 服务 端 演 染 的 实践 。 


首先 ， 新 建 一 个 应 用 react-server-koa-simple， 其 目录 结构 如 下 : 




















react-server-koa-simple/ 


上 一 app 


广 一 CSS 


| 
| 
CC package.json 


| 

| 

| | 

| | 

| | 

| | 

| | 

| | webpack.config.js 

| 广 一 middleware 

| | LL static.js (前 端 静 态 资源 托管 middleware) 
| 六 一 plugin 
| | Lreactview (reactview 插件 ) 
| Views 

| 

| 

| 

| 


一 一 layout 


| LL Default.js 


一 一 Device.js 


Home.js 
广 一 .babelrc 
上 一 -gitgnore 
app:]s 

上 一 package.json 

LREADME.md 

当然 , 我 们 需要 一 个 Koa 插件 来 做 React 模 板 演 染 , 这 正 是 7.1 节 所 讲 的 react-view。React 作 
为 服务 端 模板 的 泻 染 就 是 将 render 方法 插入 到 app 上 下 文中 ， 目 的 是 在 controller 层 中 调用 


this.render(viewFiLeName，props，chiLdren) 并 通过 this.body 输出 文档 流 至 客户 端 。 
再 来 写 一 个 用 React 实现 的 View: 


























// app/views/Home.js 

render() { 
const { microdata, mydata } = this.props; 
const homeJs = ‘${microdata.styleDomain}/build/${microdata.styleVersion}/js/home.js'; 
const scriptUrls = [homeJs]; 


return ( 
<Default 

microdata={microdata} 

scriptUrls={scriptUrls} 

title={"demo"}> 

<div id="demoApp" 
data-microdata={JSON.stringify(microdata)} 
data-mydata={JSON.stringify(mydata)}> 
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<Content mydata={mydata} microdata={microdata} /> 
</div> 
</Default> 
); 
} 





这 里 做 了 几 件 事 : 初始 化 DOM， 用 data 属性 作为 服务 端 数据 埋 点 ， 泻 染 前 后 端 公共 








Content 组 件 ， 引 用 客户 端 组 件 。 而 在 客户 端 ， 我 们 就 可 以 很 方便 地 拿 到 服务 器 的 数据 : 


import ReactDOM from "react-dom ' ; 
import Content from './components/Content.js'; 


const appELe = document.getELementById('demoApp ' ); 
Const microdata = JSON.parse(appEle.getAttribute('data-microdata' )); 
Const mydata = JSON.parse(appEle.getAttribute('data-mydata')); 


ReactDOM.render( 
<Content mydata={mydata} microdata={microdata} />， 
appEle 

); 


然后 ， 到 了 启动 Koa 应 用 的 时 候 。 下 面 我 们 来 完善 启动 入 口 app.js 来 验证 我 们 的 想法 


const koa = require('koa'); 

const koaRouter = require('koa-router'); 

const path = require('path'); 

const reactview = require('./app/plugin/reactview/app.js'); 
const Static = require('./app/middleware/static.js'); 








const App = () => { 
let app = koa(); 
let router = koaRouter(); 


// 初始 化 /home 路 由 分 派 的 generator 
router.get('/home', function* () { 
// 执行 view 插件 
this.body = this.render('Home', { 
microdata: { 
domain: '//LocaLhost:3000 ' ， 
]， 
mydata: { 
nick: 'server render body', 
]， 
]); 
]); 


app.use(router.routes()).use(router.allowedMethods()); 


// 注入 reactview 
const viewpath = path.join(__dirname, 'app/views'); 
app.config = { 
reactview: { 
viewpath: viewpath, 


}, 
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} 


reactview(app); 


return app; 


}; 


const createApp = () => { 
const app = App(); 


// http 服务 端口 监听 
app. listen(3000, () => { 
console.log('3000 is listening!'); 


})); 


return app; 


}; 

createApp(); 

现在 ， 访 问 上 面 预先 设置 好 的 路 由 ， 通 过 http://localhost:3000/home 来 验证 服务 端的 启动 ， 
如 图 7-1 和 图 7-2 所 示 。 





~V/GVVreact-server-koa-si 
3000 is listening! 
component function HomeC) { 
(0, _classCallCheck3. default)Cthis, Home); 
return (0, _possibleConstructorReturn3.default)Cthis, CHome.__proto_ I| (8, _getPrototypeOf2.default)CHome)).applyCthis, arguments)); 


master 六 


了 


reactview [markup:] DOCTYPE html> 
<html data-reactroot="" data-reactid="1" data-react-checksum="272512024"> 


<head data-reactid="2"> 
<meta charset="utf-8" data-reactid="3" /> 
<meta http-equiv="X-UA-Compatible" content="IE=edge" data-reacti 
<meta http-equiv="Cache-Control" content="no-siteapp" data-reacti, 
<meta name="renderer" content="webkit" data-reacti 
<meta name="viewport" content="width=device-width, initial-scale=1" data-reactid="7" /> 
<title data-reactid="8">demo</title> 
</head> 


<body data-reactid="9"> 
<div id="demoApp" data-microdata="{8&quot;styleDomain&quot;:&quot;//localhost: 8080&quot; ,&quot; styleVersion&quot; :&quot;1.0.0-rc4&quot;}” data-mydata="{&quot;nick&quot; :&quot;ser| 
ver render body&quot;}" data-reactid="10"> 
<div data-reactid="11"> 

react-text: 12 -->hello: 
/re -text 
react-text: 13 -->server render body 
/react-text 


</div> 
<script src="//localhost:8080/build/1.0.0-rc4/js/home.js" data-reactid="14"></script> 





图 7-1 服务 端 
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< .© localhost:3000/home 六 


hello: server render body 





[x 器 Console Profiles ” Elements Sources Network Timeline Security Application Audits Perf Redux 


<html data-reactroot data-reactid="1" data-react-checksum="272512024"> 
<head data-reactid="2"> 
<meta charset="utf-8" data-reactid="3"> 
<meta http-equi -UA-Compatible" content="IE=edge" data-reactid: 
<meta http-equiv="Cache-Control" content="no-siteapp” data-reactid="5"> 
<meta name="renderer" content="webkit" data-reactid="6"> 
<meta name="viewport" content="width=device-width, initial-scale=1" data-reactid="7"> 
<title data-reactid="8">demo</title> 
<link rel="stylesheet" href="blob:http://localhost:3000/a59bde25-8d34-46ad-ac4a-0d7c886c82d8"> 
p<style type="text/css">..</style> 
<link rel="stylesheet" href="blob:http://localhost:3000/66fca037-d028-4fd6-acec-ffab7e61c790"> 
<link rel="stylesheet" href="blob:http://localhost:3000/ala0952a-4db9-476e-8b@c-cc2892fba214"> 
<link rel="stylesheet" href="blob:http://localhost:3000/3b070535-c356-4b5b-9207-c94e08a96a5b"> 
<link rel="stylesheet" href="blob:http://localhost:3000/30a5c805-ae93-4e40-95f3-7658c69c341f"> 
<link rel="stylesheet" href="blob:http://localhost:3000/d23ebc9e-43fe-4111-aae2-9358c9b61827"> 
<link rel="stylesheet" href="blob:http://localhost:3000/b61c4fb4-7daf-4f49-9707-14262520e6ab"> 
</head> 
v<body data-reactid="9"> == $0 
v<div id="demoApp" data-microdata="{"styleDomain":"//localhost:8880","styleVersion":"1.0.0-rc4"}" data-mydata="{"nick":"server render body"}" data-reactid="10"> 
Y<div data-reactid="11"> 
<!-— react-text: 12 ~--> 
"hello;: 





























<l== /react-text- 一 > 
1 
"server render body 


lm OEt Et 
</div> 
</div> 
<script src="//localhost:8080/build/1,.0.0-rc4/is/home,.is” data-reactid="14"></script> 
</body> 
</html> 
html 





图 7-2 ”客户 端 


7.2.2” ”React-Router 和 Koa-Router 统一 





现在 ， 我 们 已 经 建立 起 服务 端 泻 染 的 基础 了 ， 接 着 再 考虑 如 何 统一 服务 端 和 客户 端的 路 由 。 
假设 我 们 的 路 由 设置 成 /devicey/ :deviceID 这 种 形式 ， 那 么 服务 端 是 怎么 实现 的 呢 ? 

















// 初始 化 device/ :deviceID 路 由 分 派 的 generator 
router .get('/device/:deviceID', function* () { 
const deviceID = this.params.deviceID; 


this.body = this.render('Device', { 
isServer: true， 
microdata: microdata, 
mydata: { 
path: this.path, 
deviceID: deviceID ， 
]， 
]); 
]); 


我 们 看 到 ,服务 端的 初始 化 非常 简单 。 当 客户 端 发 起 路 由 请 求 时 ,服务 端 就 取 到 相应 的 数据 
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并 将 其 放 到 Device 这 个 View 下 并 返回 。 我 们 再 来 看 下 Device 的 实现 : 





render() { 
const { microdata, mydata, isServer } = this.props; 
const deviceJs = `${microdata.styleDomain}/build/${microdata.styleVersion}/js/device.js’; 


const scriptUrls = [devicejJs]; 


return ( 
<Default 
microdata={microdata} 
scriptUrls={scriptUrls} 
title={"demo"}> 
<div 
id="demoApp" 
data-microdata={JSON.stringify(microdata)} 
data-mydata={JSON.stringify(mydata)}> 
<Iso 
microdata={microdata} 
mydata={mydata} 
isServer={isServer} 
/> 
</div> 
</Default> 
); 
} 


以 及 前 端 访问 app 的 入 口 实现 : 
const appELe = document.getELementById('demoApp ' ); 


function getServerData(key) { 
return JSON.parse(appEle.getAttribute( `data-Sfkey} )); 
}; 


// 从 服务 端 埋 点 处 <div id="demoApp"> 获取 microdata 和 mydata 
const microdata = getServerData('microdata'); 
const mydata = getServerData( mydata ' ) ; 


ReactDOM.render( 
<Iso microdata={microdata} mydata={mydata} isServer={false} />， 
appEle 

); 


前 后 端 公用 Isojs 模块 ， 前 端 路 由 同样 可 以 设置 成 /device/ :deviceID 这 种 形式 : 














class Iso extends Component { 
static propTypes = { 

Vo 

}; 


// 包 识 Route 的 Component， 目 的 是 注入 服务 端 传 入 的 props 
wrapComponent(Comp) { 
const { microdata, mydata } = this.props; 
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return class extends Component({ 
render() { 
return ( 
<Comp microdata={microdata} mydata={mydata}> 
this.props.children 
</Comp> 
); 
} 
}); 
} 


// LayoutView 为 路 由 的 布局 ，DeviceView 为 参数 处 理 模块 
render() { 
const { isServer, mydata } = this.props; 


return ( 
<Router history={isServer ? createMemoryHistory(mydata.path || '/') : browserHistory}> 
<Route path="/" 
component={this .wrapComponent(LayoutView)}> 
<IndexRoute component={this.wrapComponent(DeviceView)} /> 
<Route path="/device/:deviceID" component={DeviceView} /> 
</Route> 
</Router> 
); 
} 
} 


这 样 就 实现 了 服务 端 和 前 端 路 由 的 同 构 。 无 论 我 们 是 初次 访问 资源 路 径 /device/all 、 
/device/pc 、/device/wireless， 还 是 在 页 面 上 切换 这 些 资源 路 径 ， 效果 都 是 一 样 的。 这 样 既 保 证 了 
初次 泻 染 有 符合 预期 的 DOM 输出 ， 又 保证 了 代码 简洁 ， 最 重要 的 是 前 后 端 实现 用 的 同一 套 

这 里 注意 以 下 两 点 。 

口 Iso 的 render 方法 需要 判断 isserver ， 服 务 端 用 createMemoryHistory ， 前 端 用 browser- 

HtLstoryo 

口 如 果 react-router 的 组 件 需要 使 用 props， 必须 对 其 进行 包 庄 wrapComponent。 这 是 因为 服 
务 端 演 染 的 数据 需要 通过 props 的 方式 来 传递 ， 而 react-router 只 提供 了 component 的 方 
式 ， 并 不 支持 追加 props。 引 用 react-route 的 源码 : 




































































propTypes: { 


path: string, 
component: _PropTypes.component, 7 
components: _PropTypes.components, 


getComponent: func, 
getComponents: func 
}， 
为 什么 服务 端 获取 数据 不 和 客户 端 保持 一 致 ， 而 在 component 用 fetchData 作 数据 绑 定 ?” 这 
就 关系 到 接 下 来 要 探讨 的 同 构 Model 问题 。 











300 第 7 章 React 服务 端 演 > 





7.2.3” 同 构 数 据 处 理 的 探讨 


我 们 都 知道 ， 浏 览 器 端 获取 数据 需要 发 起 Ajax 请 求 。 事 实 上 ， 发 起 的 请 求 URL 对 应 着 服务 
端 一 个 路 由 控制 器 。 

React 是 有 生命 周期 的 ， 我 们 绑 定 Model 并 获取 数据 的 过 程 应 在 componentDidMount 方法 里 
完成 。 在 服务 端 ,React 是 不 会 去 执行 componentDidMount 方法 的 。 因 为 React 的 renderTranscation 
分 成 两 部 分 ReactReconcileTransaction 和 ReactServerRenderingTransaction， 在 服务 端的 实现 
只 是 移 除 了 浏览 需 端 的 一 些 方法 而 已 。 

服务 端 处 理 数据 是 线性 的 , 且 是 不 可 逆 的 , 从 发 起 请 求 、 去 数据 库 获 取 数 据 、 处 理 业 务 逻 辑 、 
组 装 成 HIML 到 输出 给 浏览 器 。 显 然 ， 服 务 端 和 浏览 句 端 是 矛盾 的 。 

我 们 或 许 会 想到 利用 ES6 classes 语法 提供 的 静态 变量 来 做 点 文章 。 确 实 ，React 为 我 们 提供 
了 入 口 ， 不 仅 能 提供 静态 属性 ， 也 能 提供 静态 方法 ， 还 能 一 起 定义 : 


/** 
* 一 个 对 象 包含 了 属性 与 方法 ， 它 用 组 件 的 构造 函数 取代 了 它 本 身 的 原型 (静态 方法 ) 
















































































* @type {object} 

* Qoptional 

3 

statics: SpecPoLicy.DEFINE_MANY， 


利用 statics 扩展 我 们 的 组 件 : 


class ContentView extends Component { 
statics: { 
fetchData: function (callback) { 
ContentData.fetch().then((data) => { 
callback(data); 
]); 
}; 





componentDidMount() { 
this.constructor.fetchData((data) => { 
this.setState({ 
data: data， 
]); 


]); 
其 中 ContentData.fetch() 需要 实现 两 套 。 


口 服务 端 : 封装 服务 端 service 层 的 方法 。 
口 浏览 器 端 : 封装 Ajax 方法 。 
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其 中 服务 端 调 用 : 


require('ContentView').fetchData((data)=> { 
this.body = this.render('Device', { 
isServer: true， 
microdata: microdata, 
mydata: data, 


}); 
}); 
这 样 的 确 可 以 解决 Model 层 的 同 构 ， 但 这 并 不 是 一 个 好 方法 ， 好 像 回 到 了 JSP 时 代 。 
当然 , 你 肯定 会 问 , 那么 Redux 可 以 实现 服务 端 泻 染 吗 ? 当然 可 以 ， 有 兴趣 的 读者 可 以 参考 


官方 文档 "。 在 GitHub 上 ， 有 一 个 关于 Redux 同 构 实现 的 热门 例子 > ， 可 以 帮助 各 位 深入 学 习 。 


7.3 ”小结 


关于 服务 端 泻 染 ， 在 本 章 中 ,我 们 只 是 初 党 其 味 ， 相 信 还 有 很 多 读者 关心 GraphQL 和 了 Relay 
在 客户 端 与 服务 端的 应 用 。 

它们 看 上 去 是 未 来 之 路 , 但 现在 为 了 它们 所 提供 的 优势 ,又 需要 编写 大 量 与 业务 逻辑 无 关 的 
代码 ,让 我 们 十 分 忧虑 该 如 何 降 低 这 套 架 构 在 实际 落地 中 的 成 本 。 随 着 技术 的 发 展 , 我 相信 会 有 
更 加 完美 的 解决 方案 产生 ， 届 时 我 们 再 来 讨论 。 









































GD server rendering， 详 见 http://cn.redux.js.org/docs/recipes/ServerRendering.html。 
© react universal hot example， 详 见 https://github.com/erikras/react-redux-universal-hot-example。 


玩 转 React 可 视 化 








DT 时 代 ， 数 据 爆 发 式 增长 ， 面 对 海量 的 数据 ， 用 户 的 注意 力 却 越 来 越 分 散 ， 如 何在 最 短 的 
时 间 内 传达 重要 的 数据 成 为 了 一 个 必须 要 解决 的 问题 。 数 据 可 视 化 就 是 为 了 解决 这 样 的 问题 , 通 
过 计算 机 图 形 、 图 像 和 交互 的 表达 增强 用 户 对 数据 的 认 知 。 

数据 可 视 化 是 一 门 交 叉 学 科 ， 集合 了 数学 、 人 工 智 能 、 图 形 图 像 、 交 互 、 视 觉 、 心 理学 等 方 
面 的 知识 。 我 们 在 Web 端 所 理解 的 可 视 化 大 都 是 线 、 柱 、 饼 等 图 表 ， 以 及 这 些 基 础 图 表 的 衍生 
和 组 合 。 在 技术 层面 , 常见 的 技术 有 SVG、Canvas、WebGL, 本 章 中 我 们 会 重点 讲述 如 何在 React 
中 使 用 Canvas 和 SVG 完成 各 种 可 视 化 需求 。 












































8.1 React 结合 Canvas 和 SVG 


Canvas 和 SVG 是 HTMLS5 中 主要 的 2D 图 形 技术 ， 前 者 提供 画布 标签 和 绘制 API， 后 者 是 一 
整套 独立 的 矢量 图 形 语 言 。 本 节 通 过 介绍 两 者 以 及 结合 使 用 这 两 者 与 React， 让 开发 者 渐渐 走 人 
可 视 化 的 世界 。 



































8.1.1 Canvas 与 SVG 
首先 ， 我 们 了 解 一 下 什么 是 Canvas 和 SVG。 


1. 什么 是 Canvas 
Canvas, 顾名思义 就 是 画布 ,是 HTML5 新 增 的 元 素 ， 主 要 用 于 图 形 图 像 相关 的 绘制 。Canvas 
基于 像素 ， 提 供 2D 绘制 函数 ， 只 能 通过 脚本 来 绘制 图 形 。 因 此 ，React 与 Canvas 并 没有 直接 的 联 
系 。 对 于 React 来 说 ，Canvas 标签 只 是 普通 HTML 标签 而 已 ， 其 处 理 方式 与 其 他 原生 标签 一 致 。 
Canvas 在 Web 端 常见 的 使 用 场景 如 下 : 
口 绘制 各 种 图 形 元 素 ， 如 多 边 形 和 Bezier 曲线 
口 图 片 图 像 处 理 
口 创建 复杂 的 动画 
口 视频 处 理 与 泻 染 
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此 外 , 在 正 浏 览 吕 上， 从 IE9 开始 兼容 Canvas。 

2. 什么 是 SVG 

SVG( Scalable Vector Graphics ), 全 称 可 缩放 矢量 图 形 , 是 一 种 用 来 描述 二 维 矢量 图 形 的 XML 
标记 语言 6SVG 是 一 个 W3C 标准 ,已 经 存在 十 几 年 了 ,能 够 与 其 他 的 W3C 标准 (如 CSS 和 DOM ) 
协同 工作 。 因 此 ，React 支持 SVG 标签 也 是 一 件 非常 自然 的 事 。 正 因为 此 ， 我 们 可 以 在 React 中 
使 用 SVG 标签 来 做 很 多 其 他 HTML 标签 做 不 了 的 事 。 

SVG 在 Web 端 常见 的 使 用 场景 如 下 : 
口 绘制 各 种 图 形 元 素 ， 如 多 边 形 和 Bezier 曲线 
口 演 染 页 面 中 的 图 标 (icon ) 
口 制作 网 站 Logo 
口 绘制 线 、 柱 、 饼 等 图 表 ， 甚 至 是 更 复杂 的 可 视 化 图 表 

此 外 ， 与 Canvas 相同 ,在 IE 上 也 是 从 IE9 开始 兼容 SVG 的 。 在 IE9 以 下 的 浏览 器 中 ,使 
用 一 种 名 为 VML 的 技术 ， 其 作用 类 似 于 SVG。React 在 15.0 版 本 中 ， 对 SVG 的 属性 和 标签 支 
持 得 比较 完善 。 

3. 比较 SVG 与 Canvas 

我 们 看 到 ， 在 图 形 元 素 的 演 染 上 ，Canvas 和 SVG 都 支持 。 事 实 上 ， 在 这 方面 ， 业 界 的 选 型 
也 各 有 不 同 ， 如 echarts 使 用 Canvas ，highcharts 使 用 的 是 SVG。 介 于 SVG 的 矢量 特性 ， 它 在 绘 
制图 形 上 更 有 优势 ， 或 者 说 更 合理 。 但 因为 SVG 在 无 线 浏 览 器 上 支持 得 并 不 理想 ， 一 些 现 代 图 
表 库 选择 用 Canvas 来 绘制 以 得 到 更 好 的 兼容 性 。 

关于 它们 的 对 比 ， 图 8-1 给 出 了 清晰 的 解释 。 


很 多 对 象 的 
复杂 场景 















































































































































视频 操作 





















图 8-1 Canvas 与 SVG 
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8.1.2 在 React 中 的 Canvas 
首先 ， 我 们 看 看 Canvas 怎么 在 React 上 实现 组 件 的 。 先 看 一 个 例子 : 








import React, { Component, PropTypes } from 'react'; 
import ReactDOM, { findDOMNode } from 'react-dom'; 


class Graphic extends Component { 
static propTypes = { 
rotation: PropTypes.number, 
color: PropTypes.string, 


}; 


static defauLtProps = { 
rotation: 0， 
color: 'green', 


}; 


componentDidMount() { 
const context = findDOMNode(this).getContext('2d'); 
this.paint(context); 


} 


componentDidUpdate() { 
const context = findDOMNode(this).getContext('2d'); 
context.clearRect(0, 0, 200, 200); 
this.paint(context); 


} 


paint(context) { 
context.save(); 
context.translate(100, 100); 
context.rotate(this.props.rotation, 100, 100); 
context.fillStyle = this.props.color; 
context.fillRect(-50, -50, 100, 100); 
Context .restore(); 


} 


render() { 
return <canvas width={200} height={200} />; 
} 

} 

这 个 例子 在 画布 上 绘制 了 一 个 正方 形 。 我 们 可 以 在 使 用 它 的 时 候 传人 rotatton 和 cotor, 来 
改变 正方 形 的 角度 和 颜色 。 我 们 看 到 ，Canvas 是 自 带 生命 周期 的 ， 包 括 初始 化 、 绘 制 和 清空 ， 
它 的 更 新 过 程 就 会 用 自 带 API， 而 不 是 setState 了 。 自 然 ， 谈 到 在 React 中 加 入 其 他 库 的 方法 ， 
就 是 指 融 合 其 他 库 的 生命 周期 方法 到 React 组 件 中 。 之 后 讲 到 D3 的 例子 时 ， 还 会 提 到 。 


Canvas 在 React 中 的 应 用 , 在 Github 上 存在 一 个 著名 的 库 react-canvas, 它 由 Flipboard 公 
司 开 发 。 请 注意 ， 它 并 不 是 可 视 化 相关 的 实现 ， 也 不 是 封装 Canvas API 的 库 ， 而 是 让 Canvas 标 
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签 奉 代 DOM， 借 助 Canvas 泻 染 的 高 性 能 和 React 组 件 化 思想 的 产物 ， 曾 经 一 度 被 视 为 移动 开发 
的 新 星 。 


8.1.3” React 中 的 SVG 


讲 到 SVG , 因为 它 的 表达 方式 更 贴近 React 使 用 原生 和 自 定义 标签 构建 组 件 化 的 思路 , 因此 ， 
后 面 也 会 主要 围绕 它 来 展开 。 首 先 ， 从 SVG 标签 实现 的 一 些 组 件 实例 开始 讲 起 。 


1. SVG 图 形 元 素 

我 们 把 SVG 图 形 元 素 分 为 基础 元 素 和 Bezier 曲线 两 类 ， 下 面 分 别 介绍 一 下 。 

@ 基础 元 素 

要 使 用 SVG 元 素来 绘制 一 些 基 础 图 形 ， 只 需要 像 使 用 其 他 DOM 标签 那样 就 行 : 


const BaseShapes = (props) => { 
return ( 
<svg width={500} height={200} viewBox="0 0 1000 400"> 
<circle cx={100} cy={200} r={80} fill="#1e74e7" fillOpacity={0.4} 
stroke="#1e74e7" strokeWidth={4} /> 
<rect x={265} y={90} width={150} height={200} fill="#99cc33" 
stroke="#99cc33" fillOpacity={0.4} strokeWidth={4} /> 
<path d="M500,200L550,200L600,50L700,350L800,50L900,350L950,200h50" 
stroke="#ffab1i8" fill="none" strokeWidth={4} /> 
</svg> 
); 
} 


效果 如 图 8-2 所 示 。 

















图 8-2 ”基本 元 素 演 染 结果 








至 此 ， 我 们 可 以 从 SVG 与 Canvas 的 实现 上 作 一 个 对 比 : SVG 本 身 就 是 一 组 组 向 套 的 标签 ， 
我 们 可 以 通过 配置 标签 的 属性 来 得 到 想 要 的 图 形 元素 ; 而 Canvas 需要 用 JavaScript 来 生成 。 在 代 
码 表现 上 ， 两 者 表现 出 了 非常 大 的 差异 。 

@ Bezier 曲线 


然后 ， 我 们 尝试 来 绘制 Bezier ( 贝 塞 尔 ) 曲线 。Bezier 曲线 需要 接收 起 点 、 终 点 、 控 制 点 这 


Wy 


3 个 控制 条 件 ， 即 我 们 需要 设置 这 3 个 prop。 这 3 个 prop 一 旦 确定 ,绘制 出 来 的 Bezier 曲线 就 re 
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一 的 : 








import React, { PropTypes } from 'react'; 


const getPath = (start, end, controlPoints) => { 
const [fx, fy, sx, sy] = controlPoints; 
const controLPointo1 = [start[0] + fx * (end[0] - start[0]), start[1] + 
fy * (end[1] - start[1])]; 
const controlPoint02 = [start[0] + sx * (end[0] - start[0]), start[1] + 
sy * (end[1] - start[1])]; 
return ‘MS${start}C${controlPoint01} ${controlPpoint02} S${end}.; 
}; 


const BezierCurve = (props) => { 
const { width, height, startPpoint, endPoint, controlPoints, ...others } 
= props; 


return ( 
<svg width={width} height={height}> 
<path 

d={getPath(startPoint, endPoint, controlPoints)} 
fill="none" 

stroke="black" 

strokeWidth="2" 

{...others} 


BezierCurve.defauLtProps = { 
width: 400 ， 
height: 400， 
controLPoints: [1/3，0，2/3，1]， 
}; 


BezierCurve.propTypes = { 
width: PropTypes.number, 
height: PropTypes.number, 
startpPoint: PropTypes.arrayOf(PropTypes.number ) ， 
endPoint: PropTypes.arrayof(PropTypes.number ) ， 
controLPoints: PropTypes.arrayOf(PropTypes.number ) ， 
}; 


接 下 来 ， 就 可 以 调用 BezierCurve 来 绘制 各 种 Bezier 曲线 了 : 


<BezierCurve 
startPpoint={[0, 300]} 
endPoint={[400，100]} 
ControLPoints={[1,0,0,1]} 
strokeWidth={6} 

/> 
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效果 如 图 8-3 所 示 。 














图 8-3 ”Bezier 曲线 的 演 染 结果 








2. SVG 图 标 
在 介绍 SVG 图 标 之 前 ， 我 们 必须 先知 道 为 什么 用 SVG 来 绘制 图 标 。 


口 我 们 常用 的 Image sprite 的 方法 有 高 清 屏 幕 的 兼容 问题 。 目 前 ， 对 于 devicePixelRatio = 
1、devicepixelRatio = 2、devicepixelRatio = 3 等 不 同 像素 比 的 屏幕 ， 为 了 使 图 标 能 够 
在 各 种 屏幕 上 都 能 正常 显示 ， 一 般 我 们 会 分 开 做 几 套 不 同比 例 的 图 片 进行 适 配 ， 一旦 某 
个 图 标 需 要 改动 ， 就 要 修改 相应 数量 的 图 片 。 

口 iconfont 字体 图 标 锯 齿 问 题 。 使 用 iconfont 时 ， 能 够 方便 地 设置 font-size 和 color 来 改 
变 图 标的 填充 颜色 和 大 小 , 并 且 能 够 自动 适 配 各 种 像素 比 的 屏幕 。 但 是 由 于 iconfont 本 身 

是 一 种 字体 文件 ， 而 浏览 器 会 对 文字 进行 抗 句 耸 优化 ， 所 以 当 图 标的 大 小 小 于 16px, 或 

者 图 标 比 较 复 如 时 ， 往 往 会 出 现 图 标 无 法 显示 清晰 的 问题 。 
对 于 上 述 问题 ，SVG 图 标 不 失 为 一 种 好 的 解决 方案 。 下 面 我 们 看 看 如 何 使 用 React 来 实现 内 

联 SVG 图 标 : 





















































const Star = ({ size = 12, fill = '#666', x=0,y=0})=>{ 
return ( 
<svg x={x} y={y} width={size} height={size} viewBox="0 0 1024 1024" 
fiLLL={fLLL}> 
<path d="M1002.656 401.856L-339.04-49.28-151.616-307.232- 
151.616 307.232-339.04 49.28 245.344 239.136-57.92 
337.664 303.264-159.424 303.264 159.424-57.92-337.664 
245.344-239.136zM512 760.544L-230.72 123.424 44.064-261.408-186.656-185.152 
257.952-38.144 115.36-237.856 115.36 237.856 257.952 
38.144-186.656 185.152 44.064 261.408-230.72-123.424z" /> 
</svg> 
); 
}; 


const Tick = ({ size = 12, fill = '#666', x=0,y=0})=>{ 
return ( 
<svg x={x} y={y} width={size} height={size} viewBox="0 0 1024 1024" 
fiLLL={fLLL}> 
<path d="M980.96 299.904L-528.864 528.864c-24.384 24.384-61.536 
28.192-89.952 11.392-5.216-3.104-10.208-6.912-14.72-11.392 0-0.032 
0-0.032 0-0.032L-304.448-304.416c-28.896-28.896-28.896-75.808 
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0-104.704s75.744-28.896 104.672 0L252.192 252.192 
476.48-476.576c28.896-28.896 75.744-28.896 104.64 0 
28.928 28.896 28.928 75.808 0 104.67210 0z" /> 
</svg> 
); 
}; 


它 的 实现 原理 是 把 图 标的 绘制 路 径 通过 设置 path 标签 的 方法 转换 成 SVG 组 件 。 这 样 ， 我 们 
可 以 方便 地 在 任何 地 方 插入 图 标 : 

















<div> 
<p>This is a Tick: <Tick size={16} fill="#96c7fa" /></p> 
<p>This is a Star: <Star size={20} fill="#1e74e7" /></p> 
</div> 


效果 如 图 8-4 所 示 。 
This is a Tick: 


This is a Star: YY 





图 8-4 图标 泻 染 结果 
使 用 这 种 内 联 SVG 图 标 ， 想 要 组 合 图 标 就 变 成 了 一 件 很 简单 的 


<svg width={24} height={24}> 

<Star size={20} fill="#96c7fa" /> 

<Tick size={10} x={12} y={12} fill="#1e74e7" /> 
</svg> 


效果 如 图 8-5 所 示 。 
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图 8-5 ”组 合 图 标的 演 染 结果 


3. 网 站 Logo 


SVG 格式 的 Logo 能 够 非常 方便 地 修改 尺寸 ， 填 充 颜 色 ， 并 且 可 以 非常 方便 地 做 出 酷 炫 的 生 
成 动画 。 下 面 我 们 看 一 个 例子 : 


const Logo = () => { 
return ( 
<div> 
<CSSTransitionGroup transitionName="logo" component="div" transitionAppearTimeout={4000} 
transitionAppear={true} transitionEnter={false} transitionLeave={false}> 
<svg height="300" viewBox="0 0 404.7 354" key="svg"> 
<path id="hi-path" fill="none" stroke="#000" d="M324.6, 
61.2c16.6,0,29.5-12.9,29.5-29.5c0-16.6-12.9-29.5-29.5-29.5c-16.6， 
0-29.5,12.9-29.5,29.5C295.1,48.4,308,61.2,324.6,61.2zM366.2， 
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204.2c-9.8,0-15-5.6-15-15.1V77.2h-85v28h19.5c9.8,0,8.5,2.1,8.5, 
11.6v72.4c0,9.5,0.5,15.1-9.3,15.1H277h-20.7c-8.5, 
0-14.2-4.1-14.2-12.9V52.4c9-8.5,5.7-12.3,14.2-12.3h18.8v-28h-127v28h18.1c8.5， 
0,9.9,2.1,9.9,8.9v56.1h-75V53.4c0-11.5,8.6-13.3, 

17-13.3h1iiv-28H2.2v28h26c8.5,0,12,2.1,12,7.9v142.2c0, 
8.5-3.6,13.9-12,13.9h-21v33h122v-33h-11c-8.5,0-17-4.1-17-12.2v-57.8h75v58.4c0, 


9.1-1.4,11.6-9.9,11.6h-18.1v33h122.9h5.9h102.2v-33H366.2z" /> 


</svg> 
</CSSTransitionGroup> 
</div> 
); 
}; 


效果 如 图 8-6 所 示 。 





其 中 SCSS 代码 如 下 : 


svg > path { 
stroke: #ff7300; 








图 8-6 


网 站 Logo 演 染 结果 


stroke-dasharray: 2401px 2401px; 


stroke-dashoffset: 0; 
} 


.Logo-appear path { 
stroke-dashoffset: -2401px; 
J 


.logo-appear-active path { 
stroke-dashoffset: 0; 


transition: stroke-dashoffset 4s ease 1s; 


} 





在 这 个 例子 中 ， 我们 使 用 stroke-dashoffset 和 stroke-dasharray 


动画 效果 。 不 难看 出 ，SVG 元 素 的 





属性 也 可 以 作为 transition 的 对 象 。 





属性 快速 实现 了 Logo 的 


本 节 中 ， 我 们 通过 学 习 Canvas 和 SVG 在 React 中 的 用 法 ， 对 它们 实现 组 件 化 有 了 初步 的 


认识 。 
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8.2 React 与 可 视 化 组 件 


在 还 没有 React 的 时 候 ， 绘 制图 表 或 可 视 化 作品 时 ， 我 们 通常 有 两 种 选择 ; 


口 使 用 可 视 化 组 件 库 ， 像 echarts 、Highcharts 、c3 、chartist 等 ; 
口 借助 可 视 化 基础 库 Raphael、D3 来 自 定义 绘制 一 些 可 视 化 作品 。 


使 用 了 React 后 ， 想 要 去 做 一 些 图 表 、 可 视 化 作品 ， 一 般 会 采用 以 下 几 种 做 法 : 


口 创建 React 组 件 来 包装 已 有 的 可 视 化 组 件 库 ， 如 react-chartist、react-c3 等 ; 
口 创建 React 组 件 来 接收 各 种 参数 ， 获 取 DOM 节点 后 ， 仍 使 用 Raphael、D3 或 者 Canvas 等 


























来 演 染 具体 的 UI 部 分 ; 
口 调用 D3 等 库 中 提供 的 算法 ,使 用 React 来 绘制 UI 部 分 ， 包 括 泻 染 SVG 节点 、DOM 节 
点 等 。 





下 面 简单 介绍 一 下 Raphael 和 D3 这 两 个 可 视 化 基础 库 。 

Raphael 可 以 说 是 SVG 界 的 jQuery， 提 供 了 非常 丰富 的 API， 让 开发 者 能 够 非常 方便 地 操作 
SVG 元 素 。 在 IE8 及 以 下 浏览 器 中 ,会 使 用 VML (Vector Markup Language ) 来 绘制 图 形 元 素 ， 
在 支持 SVG 的 浏览 器 中 使 用 SVG 来 绘制 。 它 能 够 很 好 地 兼容 各 种 浏览 需 版 本 ， 因 此 使 用 非常 广 
泛 。 当 然 ， 缺 点 就 是 Raphael 中 没有 提供 任何 可 视 化 算法 的 内 容 ， 需 要 开发 者 自己 实现 或 者 调用 
一 些 其 他 的 库 。 

D3 相对 而 言 对 浏览 器 的 支持 不 是 很 好 ， 只 支持 IE9 及 以 上 的 浏览 器 。D3 的 特点 是 将 数据 与 
节点 绑 定 (包括 DOM 节点 和 SVG 节点 ), 能 够 非常 方便 地 实现 各 种 动态 数据 可 视 化 。 并 且 D3 内 
置 了 非常 丰富 的 图 表 算法 ,使 得 绘制 一 些 复杂 图 表 变 得 简单 。 

随 着 浏览 器 的 发 展 ,IE8 及 以 下 的 浏览 器 使 用 占 比 不 断 下 降 ,D3 慢 慢 成 为 更 多 开发 者 的 选择 。 
接 下 来 ,我 们 会 主要 以 D3 为 例 讲述 用 React 玩 转 可 视 化 的 方法 。 












































8.2.1 包装 已 有 的 可 视 化 库 


在 实际 的 开发 过 程 中 ， 如果 团 队 不 具备 开发 可 视 化 组 件 的 能 力 , 或 者 时 间 紧 张 , 没有 足够 的 
时 间 重 新 开发 新 的 可 视 化 组 件 时 ， 将 已 有 的 可 视 化 组 件 进行 “包装 ”来 达到 在 React 组 件 中 使 用 
的 目的 不 失 为 一 种 好 办 法 。 下 面 看 看 怎么 包装 一 个 已 有 的 可 视 化 组 件 库 。 

首先 ， 假设 我 们 已 有 一 个 XChart 组 件 ， 通 常会 这 么 使 用 : 


const container = document.getElementById('#container'); 
const chart = new XChart(container, data, options); 





























chart.update(data, options); 
chart.destory(); 
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要 包装 这 样 一 个 组 件 ， 需 要 将 这 个 组 件 的 API 与 React 生命 周期 相 结 合 
import React, { PropTypes，Component } from 'react'; 


class ReactXChart extends Component { 
componentDidMount() { 
const container = ReactDOM.findDOMNode(this); 
const { data, options } = this.props; 


this.chart = new XChart(container, data, options); 


} 


componentDidUpdate() { 
const { data, options } = this.props; 


if (this.chart) { 
this.chart.update(data, options); 
} 
} 


componentWillUnmount() { 
if (this.chart) { 
this.chart.destory(); 
this.chart = null; 
} 
} 


render() { 
return <div class="x-chart-wrapper"></div>; 

} 
} 
通过 ReactXChart 的 代码 实现 可 以 发 现 ， 包 装 代 码 主 要 是 将 xchart 实例 的 方法 与 React 生命 
周期 相 结 合 。 当 Reactxchart 的 DOM 节点 被 创建 后 ， 新 建 XChart 实例 ; 当 ReactXChart 发 生 了 
更 新 后 ,更 新 XChart 实例 ; 当 ReactxChart 被 卸载 之 前 , 移 除 xchart 实例 。 最 终 我 们 通过 构建 React 
组 件 来 使 用 : 


<ReactXChart data={data} options={options} /> 


这 种 实现 方法 成 本 比较 低 ， 只 需要 做 一 些 包 装 。 当 然 , 缺点 也 很 明显 ， 即 基本 上 泻 染 操 作 在 
组 件 内 部 还 是 DOM 操作 ， 只 是 在 外 部 套 了 一 个 React Component 的 壳 而 已 ， 实 质 上 并 没有 用 到 
React Virtual DOM。 





























8.2.2 ”使 用 D3 绘制 Ul 部 分 


在 React 项 目 中 ， 如 果 需 要 开发 新 的 可 视 化 组 件 ， 包 装 已 有 的 组 件 估 计 就 行 不 通 了 ， 这 时 候 
可 以 考虑 基于 D3 来 实现 。D3 是 业界 使 用 最 为 广泛 的 可 视 化 基础 库 之 一 ， 但 它 和 了 eact 的 | 思想 有 
很 多 相 违背 的 地 方 。 
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口 D3 支持 数据 与 节点 绑 定 ， 当 数据 发 生变 化 时 ， 节 点 自动 发 生变 化 。 而 React 推崇 的 是 单 
向 数据 流 ， 数 据 从 父 组件 流 向 子 组 件 ， 每 个 子 组 件 只 实现 较 简 单 的 一 个 模块 。 
口 D3 实现 了 一 套 selector 机 制 ， 能 够 让 开发 者 直接 操作 DOM 节点 、SVG 节点 。React 使 用 


Virtual DOM 和 高 性 能 DOM diff 算法 ， 让 开发 者 不 用 关心 节点 操作 。 
想 要 把 这 两 个 库 结 合 起 来 ， 看 起 来 是 一 件 非常 麻烦 的 事情 。 但 好 在 React 是 一 个 非常 轻 量 级 





的 库 ， 使 用 一 些小 技巧 就 能 够 在 React 组 件 中 使 用 D3 做 我 们 想 要 做 的 寻 


单 的 柱 图 为 例 进 行 讲述 。 








和 情 。 下 面 以 绘制 一 个 简 


首先 ， 定 义 好 BarChart 接收 的 props。 由 于 D3 需要 操作 DOM 节点 ， 所 以 render 也 非常 简 


单 ， 只 需要 演 染 一 个 div 作为 容器 即 可 : 
import React, { PropTypes, Component } from 'react'; 


class BarChart extends Component { 
static propTypes = { 
width: PropTypes.number, 
height: PropTypes.number, 
data: PropTypes.arrayOof(PropTypes.number ) ， 
margin: PropTypes.shape({ 
top: PropTypes.number, 
right: PropTypes.number, 
bottom: PropTypes.number, 
left: PropTypes.number, 
})， 
}; 


static defauLtProps = { 
margin: { top: 0, right: 0, bottom: 0, left: 0 }; 
}; 


render() { 
return <div className="bar-chart" ref="container"></div>; 
} 
} 





然后 再 来 实现 UI 部 分 的 逻辑 。 对 于 绘制 柱 图 ， 首 要 的 就 是 给 X 轴 和 立轴 都 分 别 创建 相应 的 
刻度 函数 。 这 里 我 们 调用 d3-scale 提供 的 scaleLinear 来 创建 Y 轴线 性 的 刻度 函数 ， 调 用 





scaleBand 来 创建 X 轴 离 散 的 刻度 函数 : 
import { scaleLinear, scaleBand } from 'd3-scale'; 


const getXScale = (data, width, height, margin) => { 
return scaleBand() 
.domain(d3.range(data. length)) 
.range([margin.left, width - margin.right]); 
}; 


const getYScale = (data, width, height, margin) => { 
return scalelLinear() 
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.domain([0, d3.max(data)]) 
.range([height - margin.bottom, margin.top]); 


}; 


接着 ， 开 始 实现 图 表 初 始 化 的 逻辑 。 这 段 逻 辑 需 要 在 DOM 被 创建 后 才 调 用 ， 也 就 是 
componentDidMount 中 被 调用 ， 实 现 如 下 : 

















componentDidMount() { 

const { width, height, data, margin, fillColor } = this.props; 
const xScale = getXScale(data, width, height, margin); 
const yScale = getYScale(data, width, height, margin); 
const yRange = yScale.range(); 
const container = this.refs.container; 
const chart = d3.select(container) 

.append('svg') 

.attr('width', width) 

.attr('height', height); 
const barWidth = xScale.bandwidth(); 
const bars = chart.selectAll(' .bar ') 

.data(data); 


bars.enter() 

append('g') 
.Clssed('.bar', true) 
.attr('transform', (d, i) => ‘translate(${margin.left + i * barWidth}, 0).); 
.append('rect') 
.attr('y', d => yScale(d)) 
.attr('height', d => yRange[0] - ysScale(d)) 
.attr('width', d => barWidth - 1) 
.attr('fill', fillColor); 

} 


通过 上 面 的 例子 可 以 看 到 ， 这 种 方法 与 只 使 用 D3 实现 可 视 化 组 件 的 差别 很 小 ， 熟 悉 D3 的 
开发 者 能 够 很 快 上 手 。 当 然 ， 这 种 实现 方法 的 缺点 同样 是 无 法 利用 Virtual DOM， 内 部 演 染 还 是 
直接 操作 DOM。 






































8.2.3 使 用 React 绘制 UI 部 分 

最 后 ,我 们 讲述 的 是 一 种 更 加 纯粹 的 实现 可 视 化 组 件 的 方法 。 在 这 种 实现 中 , 我们 不 再 借助 
于 任何 D3 的 DOM 操作 ， 所 有 的 UI 使 用 React 来 实现 ，D3 只 负责 一 些 算法 部 分 。 为 了 加 深 大 
家 对 D3 和 React 分 工 的 理解 ， 我 们 来 实现 一 个 简单 的 线 图 。 

首先 ， 还 是 分 析 一 下 整体 布局 。 这 里 就 不 重复 列 出 propTypes 和 defaultProps， 以 及 声称 刻 
度 函 数 的 代码 部 分 了 : 


import React, { propTypes } from 'react'; 
import { line as shapeLine, curveMonotoneX } from 'd3-shape'; 









































const propTypes = { ...}; 
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const defauLtProps = { ...}; 


const LineChart = (props) => { 
const { width, height, data, margin } = props; 
const xScale = getXScale(data, width, height, margin); 
const yScale = getYScale(data, width, height, margin); 


return ( 
<div> 
<svg width={width} height={height}> 
{renderXAxis(xScale, width, height, margin)} 
{renderYAxis(yScale, width, height, margin)} 
{renderpath(data, xScale, yScale)} 
</svg> 
</div> 
); 
}; 


LineChart.propTypes = propTypes; 
LineChart.defauLtProps = defaultProps; 


再 来 看 一 下 线 图 各 个 组 件 的 实现 方法 : 


const renderXAxis = (scale, width, height, margin) => { 
const y = height - margin.bottom; 


























const ticks = scale.domain().map((entry, index) => { 
return ( 
<g className="x-axis-tick" key={ tick-${index} }> 
<line xl={fentry} x2={entry} y1={y} y2={y - 6} stroke="#808080" /> 
<text x={entry} y={y - 20} textAnchor="middle">{index - 1}</text> 
</g> 
); 
}); 


return ( 
<g className="x-axis"> 
<Line x1l={margin.left} yi={y} x2={width-margin.right} y2={y} 
stroke="#808080" /> 
{ticks} 
</g> 
); 
}; 


const renderYAxis = (scale, width, height, margin) => { 
const x = margin.Left; 


const ticks = scale.ticks(5).map((entry, index) => { 
const y = scale(entry); 


return ( 
<g className="y-axis-tick" key={ tick-${index} }> 
<line y1={y} y2={y} xl={x - 6} x2={x} stroke="#808080" /> 
<text x={x - 10} y={y} dy={8} textAnchor="end">{entry}</text> 
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return ( 
<g className="y-axis"> 
<line x1={x} x2={x} y1={margin.top} y2={height - margin.bottom} 
stroke="#808080" /> 
{ticks} 
</g> 
); 
}; 


const renderPath = (data, xScale, yScale) => { 
const points = data.map((entry, index) => [xScale(index), yScale(entry)]); 
const 1 = shapeLine() 
.x(p => p[0]) 
.y(P => p[1]) 
.defined(p => p[0] === +p[0] && p[1] === + p[1]) 
.Curve(curveMonotoneX); 
const path = l(points); 


const dots = points.map((entry, index) => ( 
<circle key={ dot-${index}’} cx={entry[0]} cy={entry[1]} r={4} 
strokeWidth={2} fill="#fff" stroke="#ff7300" />; 
)); 


return ( 
<g className="line"> 
<path d={path} fill="none" stroke="#ff7300" strokeWidth={2}/> 
{dots} 
</g> 
); 
}; 


在 以 上 例子 中 ， 我 们 使 用 了 d3-scale 中 的 算法 来 生成 X 轴 和 YY 轴 的 刻度 函数 ， 使 用 d3-shape 
中 的 曲线 算法 来 生成 光滑 曲线 ， 而 最 后 的 节点 都 是 通过 React 标签 来 实现 的 。 这 种 实现 方法 和 之 
前 两 种 方法 最 大 的 不 同 就 是 能 够 利用 Virtual DOM， 是 React 标准 的 实现 方式 。 


业界 关于 React 与 D3 的 结合 , 有 两 个 相对 关注 度 比 较 高 的 组 件 库 : react-d3、react-d3-components。 


这 两 个 组 件 库 都 是 使 用 React 来 做 UI 部 分 的 泻 染 ，D3 负责 算法 部 分 ， 使 用 方法 与 我 们 的 示 
例 类 似 。 下 面 我 们 以 react-d3 为 例 来 看 一 下 : 


<LineChart 
legend={true} 
data={lineData} 
width='100%' 
height={400} 
viewBoxObject={{ 
Xe 
y: 0， 
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width: 500， 
height: 400， 

}} 

title="Line Chart" 

yAxisLabel="Altitude" 

xAxisLabel="Elapsed Time (sec)" 

domain={{ x: [,10], y: [-10,] }} 

gridHorizontal={true} 
/> 
可 以 发 现 ， 这 种 图 表 将 原来 可 能 非常 复杂 的 配置 项 都 放 到 props 中 去 了 。 虽 然 使 用 起 来 还 是 

比较 方便 ， 但 是 缺乏 可 扩展 性 和 定制 性 ，props 也 可 能 变 得 非常 庞大 。 
我 们 再 看 Recharts 、Victory 这 两 个 组 件 库 ， 它 们 的 特点 是 ， 对 图 表 的 组 件 化 使 用 了 React 标 
准 实现 的 方式 。 使 用 Recharts 创建 曲线 图 的 代码 如 下 : 

<LineChart width={600} height={400} data={data}> 

<YAxis type='number' yAxisId={0} /> 

<YAxis type='number' orientation='right' yAxisId={1} /> 

<XAxis dataKey='name' /> 

<Tooltip /> 

<CartesianGrid stroke='#f5f5f5' /> 

<Line dataKey='key01' stroke='#ff7300' strokeWidth={2} yAxisId={0} /> 

<Line dataKey='key02' stroke='#387908' strokeWidth={2} yAxisId={1} /> 
</LineChart> 


这 类 图 表 组 件 库 的 特点 是 : 
口 语义 化 ， 配 置 简单 ，; 
口 可 扩展 性 强 ， 支 持 定制 化 需求 。 
当然 ， 需 要 开发 者 对 整个 组 件 库 中 提供 的 组 件 都 较为 了 解 ， 否 则 会 难以 使 用 。 在 下 一 节 里 ， 
我 们 会 仔细 讲述 Recharts 组 件 化 的 原理 。 


8.3 Recharts 组 件 化 的 原理 

Recharts 是 2016 年 年 初 开源 的 一 款 可 视 化 组 件 库 ， 为 基础 表格 的 绘制 提供 了 另外 一 种 可 能 。 
接 下 来 ,我 们 从 设计 思想 层面 来 剖析 Recharts 的 原理 和 精髓 。 

回顾 一 下 在 做 图 表 类 的 需求 时 ， 碰 到 的 最 纠结 的 问题 是 什么 ? 

首先 , 一 般 来 说 ， 图表 的 配置 非常 复杂 ， 可 配置 的 内 容 太 多 ， 找 不 到 到 底 使 用 什么 配置 项 来 
达到 想 要 的 目的 ; 再 者 , 很 多 样式 无 法 完全 统一 ， 变 化 很 多 。 线 图 中 多 条 参考 线 怎 么 实现 ?” 柱 图 
的 “ 柱 形 ” 怎 么 变 成 三 角形 呢 ? 

那么 ，Recharts 是 怎么 解决 这 些 问 题 呢 ? 
口 声明 式 的 标签 ， 让 写 图 表 和 写 HTML 一 样 简单 。 
口 贴近 原生 SVG 的 配置 项 ， 让 配置 项 更 加 自然 。 
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口 接口 式 的 API， 解 决 各 种 个 性 化 的 需求 。 
下 面 我 们 将 仔细 分 析 这 些 是 怎么 实现 的 。 

















8.3.1 声明 式 的 标签 
我 们 通过 创建 一 个 自 定 义 的 线 图 来 感受 Recharts 的 实现 。 
首先 ， 通 过 调用 LineChart 添加 一 条 datakey 为 a 的 线 图 : 

















Const data = [ 
{ name: '01', a: 4000, b: 2400 }， 
{ name: '02', a: 3000, b: 1398 }, 


]; 
<LineChart width={600} height={300} data={data}> 


<Line dataKey="a" stroke="#8884d8" /> 
</LineChart> 


效果 如 图 8-7 所 示 。 


图 8-7 简单 的 线 图 











这 是 最 简单 的 线 图 。 接 着 我 们 可 以 丰富 它 ， 比 如 为 它 增加 X 轴 和 Y 轴 ， 此 时 只 


LineChart 下 添加 XAxis 和 YAxis 组 件 即 可 : 


const data = [ 
{ name: '01', a: 4000, b: 2400 }, 
{ name: '02', a: 3000, b: 1398 }, 


J; 


<LineChart width={600} height={300} data={data}> 
<XAxis /> 
<YAxis /> 
<Line dataKey="a" stroke="#8884d8" /> 
</LineChart> 


效果 如 图 8-8 所 示 。 
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图 8-8 增加 X 轴 和 YY 轴 的 线 图 


可 以 看 到 ， 用 Recharts 绘制 图 表 时 ， 很 多 时 候 就 像 拼 积木 一 样 ， 那 么 LineChart 内 部 是 如 何 
去 识别 这 些 “ 零 件 ” 的 呢 ? 先 来 看 一 个 简单 的 函数 : 
const getDisplayName = (Comp) => { 
if (!Comp) { return ''; } 
if (typeof Comp === 'string') { return Comp; } 
return Comp.displayName || Comp.name || "Component '; 
}; 
getDisplayName 方法 用 来 读 取 某 个 React 组 件 的 displayName。 因 为 除了 ES6 classes 方式 构 
建 的 组 件 没有 displayName 外 ， 其 他 构建 方法 都 可 以 读 取 这 个 静态 变量 。 为 了 区 分 不 同 组 件 ， 我 
们 需要 一 个 标识 ， 而 displayName 就 是 那个 标识 。 同 时 也 说 明 如 果 是 相同 名 字 的 组 件 ， 是 没有 办 
法 匹配 到 具体 哪 一 个 ， 只 能 全 列 出 来 。 在 LineChart 的 实现 中 ， 就 是 根据 组 件 的 dispLayName 来 
识别 所 有 的 子 组 件 的 。 
此 外 ,调用 子 组 件 时 ， 尤 其 是 子 组 件 是 自 定义 组 件 时 ， 我 们 经 常会 对 它们 的 props 进行 一 定 
的 改造 ,这 时 就 需要 操作 具体 的 子 组 件 。 这 时 , 我 们 就 可 以 利用 getDisplayName 函数 识别 类 型 并 
遍历 子 组 件 得 到 结果 ， 具 体 实现 如 下 : 
const findAllByType = (children, type) => { 


const result = []; 
let types = []; 













































































if (Array.isArray(type)) { 

types = type.map(t => getDisplayName(t)); 
} elsef{ 

types = [getDispLayName(type)]; 
} 


React.Children.forEach(children, child => { 
const childType = child && child.type && (child.type.displayName || child.type.name); 
if (types.indexof(childType) !== -1) { 
result.push(child); 
} 
}); 
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return result; 


}; 
这 里 type 可 以 是 ReactComponent 或 者 ReactComponent 数组。 而 在 LineChart 内 部 ， 就 是 调 
用 这 个 方法 来 识别 各 个 “和 零件” 的: 








render() { 
const { children } = this.props; 
const LineItems = findAllByType(children, Line); 


8.3.2 ”贴近 原生 的 配置 项 


图 表 的 配置 项 非常 多 , 但 是 有 很 多 配置 项 ( 如 填充 颜色 、 描 边 颜 色 、 描 边 宽度 等 ) 都 是 SVG 
标签 原生 就 支持 的 属性 。 为 了 减少 配置 成 本 ，Recharts 的 组 件 会 去 解析 原生 的 属性 。 比 如 ， 在 线 
图 中 有 两 条 曲线 ， 我 们 想 把 其 中 一 条 曲线 设置 成 虚线 ， 一 条 设置 成 实 线 ， 此 时 只 需要 像 原生 的 
SVG 元 素 那 样 设置 stroke-dasharray 属性 ， 在 React 中 转换 成 小 驼峰 就 可 以 : 

Const data = [ 


{ name: '01', a: 4000, b: 2400 }， 
{ name: '02', a: 3000, b: 1398 }, 



































J; 


<LineChart width={600} height={300} data={data}> 
<XAxis /> 
<YAxis /> 
<Line dataKey="a" stroke="#8884d8" strokeDasharray="5 5" /> 
<Line dataKey="b" stroke="#82ca9d" /> 





</LineChart> 
此 时 得 到 的 效果 如 图 8-9 所 示 。 
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图 8-9 ” 线 图 


事实 上 ，Recharts 内 部 维护 了 一 份 SVG 元 素 支持 的 所 有 属性 。 在 泻 染 SVG 元 素 之 前 ， 它 会 
去 解析 相应 的 ReactElement 的 props， 看 哪些 是 SVG 元 素 能 够 支持 的 属性 ， 最 终 支持 的 属性 将 被 
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传 入 到 渲染 的 SVG 元 素 中 : 


Const PRESENTATION_ATTRIBUTES = { 
fill: PropTypes.string, 
strokeDasharray: PropTypes.string, 


}; 


const getPresentationAttributes = (el) => { 
if (!el || _.isFunction(el)) { return null; } 


const props = React.isValidElement(el) ? el.props : el; 
let result = null; 


for (const key in props) { 
if (props.hasOwnProperty(key) && PRESENTATION_ATTRIBUTES[key]) { 
if (!result) {result = {};} 
result[key] = props[key]; 
3 
} 


return result; 


}; 


8.3.3 接口 式 的 API 


很 多 时 候 , 基础 图 表 往 往 不 能 满足 所 有 的 要 求 , 如 何 去 满 足 各 种 个 性 化 的 场景 成 为 图 表 组 件 
必须 要 考虑 的 问题 。 


Recharts 对 可 能 会 变化 的 元 素 都 提供 了 自 定义 的 接口 。 以 X 轴 的 刻度 为 例 ， 普 通 的 刻度 就 是 
一 组 字符 串 , 在 信息 图 表 中 , 为 了 让 图 表 更 加 生动 , 视觉 上 往往 希望 通过 将 文字 替换 成 形象 的 图 
标 来 达到 增强 体验 。 


对 于 这 样 的 自 定 义 场景 ，Recharts 提供 了 两 种 方式 。 第 一 种 是 通过 React 组 件 的 方式 : 


const CustomizedTick = ({ x, y, payload, bgColor, index }) => { 

return ( 
<g> 

<circle cx={x} cy={y + 15} r={10} fill={bgColor} /> 

<text x={x} y={y + 22} textAnchor="middle" fill="#fff">{index}</text> 
</g> 
); 
}; 





























<LineChart data={data}> 
<XAxis tick={<CustomizedTick bgColor="#666" />} /> 
<YAxis /> 
<Line dataKey="a" stroke="#8884d8" strokeDasharray="5 5" /> 
<Line dataKey="b" stroke="#82ca9d" /> 
</LineChart> 
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效果 如 图 8-10 所 示 。 
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图 8-10 ” 线 图 


这 里 通过 将 tick 设置 成 一 个 React 组件 ， 在 拿 到 内 部 props 的 同时 ， 也 可 以 非常 方便 地 从 外 
部 传人 props。 


第 二 种 自 定义 的 方式 是 通过 方法 : 


Const renderCustomizedTick = ({ x, y, payload, index }) => { 
return ( 
<g> 
<circle cx={x} cy={y + 15} r={10} fill="#666" /> 
<text x={x} y={y + 22} textAnchor="middle" fill="#fff"> {index}</text> 
</g> 
); 
}; 








<LineChart data={data}> 
<XAxis tick={renderCustomizedTick} /> 
<YAxis /> 
<Line dataKey="a" stroke="#8884d8" strokeDasharray="5 5" /> 
<Line dataKey="b" stroke="#82ca9d" /> 
</LineChart> 
其 中 renderCustomizedTick 方法 中 拿 到 的 参数 和 customizedTick 的 props 一 样 。 当 然 ， 这 种 自 定 
义 的 方法 较为 传统 ， 更 容易 理解 。 
看 到 这 里 ， 各 位 可 能 会 好 奇 Recharts 内 部 到 底 是 怎么 实现 的 。 事 实 上 ，Recharts 在 内 部 已 经 
计算 好 了 tick 的 位 置 等 基本 信息 ， 然 后 判断 tick 参数 的 类 型 。 我 们 可 以 简化 一 下 内 部 实现 ， 具 
体 代 码 如 下 : 


let tiLckItem; 











if (React.isValidElement(tick)) { 
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tickItem = React.cloneElement(tick, props); 
} else if (_.isFunction(tick)) { 
tickItem = tick(props); 
} else { 
tickItem = <text {...props} className="recharts-cartesian-axis-tick-value">{value}</text>; 


} 


看 到 这 里 ,我们 就 知道 Recharts 内 部 主要 是 计算 各 种 布局 , 每 个 区 块 具体 展示 什么 内 容 都 是 
可 以 自 定 义 的 。 
Recharts 实现 可 视 化 组 件 的 核心 思想 不 只 适用 于 可 视 化 组 件 ， 一般 有 层级 关系 的 组 件 都 可 以 
用 这 种 思想 来 实现 。 例 如 ， 表 格 组 件 就 可 以 抽取 Column 组 件 ， 这 样 我 们 可 以 精细 化 地 控制 每 一 
列 的 显示 与 配置 : 
<Table data={data}> 
<Column name=" 名 称 " dataKey="name" /> 
<Column name=" 数 量 " dataKey="count" align="right" th={<SortableTh order="asc" 
onChange={handleSort} />} /> 
<Column name=" 人 金额 "dataKey="price" td="float" align="right" /> 
</Table> 
这 种 思想 在 React 中 并 不 少见 。React 本 身 就 推崇 分 而 治之 的 思想 ， 组 件 的 组 成 部 分 本 身 也 
是 组 件 ， 这 样 就 可 以 在 一 定 约束 条 件 下 使 用 自 定义 达到 我 们 的 目的 。 















































8.4 小 结 


本 章 介绍 了 如 何在 React 框架 中 使 用 Canvas 和 SVG 来 完成 各 种 可 视 化 的 需求 ,以 及 Recharts 
组 件 化 的 思想 ， 和 希望 读者 可 以 对 React 可 视 化 有 一 个 全 面 的 了 解 ， 并 能 够 拥有 开发 可 视 化 组 件 的 
能 力 。 

然而 如 本 章 开 始 所 说 ， 可 视 化 是 一 个 很 大 的 命题 ， 并 不 只 是 做 线 、 柱 、 饼 图 ，React 在 这 其 
中 扮演 的 角色 尽管 只 体现 在 泻 当 层 上 , 但 它 给 可 视 化 构建 提供 了 一 个 全 新 的 选项 , 也 许 在 未 来 我 
们 会 看 到 与 可 视 化 算法 集合 结合 得 更 好 的 库 。 





























开发 环境 











任何 库 或 框架 首先 得 有 一 个 运行 环境 ，React 工程 也 不 例外 。 但 考虑 到 前 端 发 展 日 新 月 异 ， 
工具 的 迭代 更 新 非常 快 , 希望 读者 可 以 识别 什么 是 不 变 的 ,什么 是 变化 的 ， 从 而 选择 合适 的 开发 
工具 。 下 面 我 们 就 以 React 开发 环境 为 例 讲述 开发 环境 的 组 成 与 搭建 。 






































A.1 运行 开发 环境 : Node.js 


近 几 年 ，JavaScript 组 件 化 的 生态 系统 一 直 在 进步 ， 其 中 维持 一 套 生 态 系 统 最 重要 的 就 是 需 
要 定义 一 套 公 认 的 模块 规范 。 尽 管 出 发 点 是 美好 的 ， 但 不 可 避免 地 出 现 了 竞争 的 局 面 。 到 今天 ， 
主流 的 模块 规范 有 两 种 一 一 AMD 和 CommonJS 标准 。 此 外 ， 还 有 把 它们 两 者 统一 的 通用 模块 规 
范 UMD 标准 。 

这 三 者 的 实现 与 理念 不 在 本 书 的 讨论 范围 之 内 , 不 过 我 们 需要 为 此 书 选 择 一 套 模块 规范 ,这 
也 是 React 官方 及 社区 比较 推崇 的 方案 。 因 此 ， 在 此 声明 : 在 本 书 出 现 的 代码 ， 除 源 代码 之 外 ， 
均 统 一 使 用 CommonJS 标准 ，npm 包 管 理 系 统 ， 通 过 Babel 编译 ES2015/ES6 ( ES6 与 ES2015 是 
同一 个 标准 ECMA-262，ES6 是 民间 说 法 ，ES2015 是 官方 发 布 版 本 时 使 用 的 正式 名 字 ) 语法 ， 
使 用 webpack 打包 测试 及 发 布 。 

此 外 ， 为 了 和 系统 环境 保持 一 致 ， 我 们 约定 本 书 运行 的 开发 系统 是 Mac OS 系统 。 当 然 , 在 
Linux 和 Window 下 ， 通 过 类 似 的 方法 都 可 以 搭建 运行 环境 ， 但 是 这 不 在 本 书 的 讨论 范围 之 内 。 

我 们 通过 讲述 一 个 项 目 工 程 目 录 的 初始 化 过 程 , 来 完成 开发 环境 中 一 系列 标准 与 工具 配合 下 
的 配置 与 启动 过 程 。 


首先 ， 在 任意 一 个 文件 夹 下 新 建 目录 ， 这 里 假设 这 个 工程 是 我 们 的 第 一 个 React App， 取 名 
为 first-react-app: 
















































































































































































$ mkdir first-react-app && cd first-react-app 


首先 安装 Node.js， 这 里 推荐 使 用 NVM" 来 管理 不 同 的 Nodejjs 版 本 。NVM 的 安装 方法 可 以 








Q@NVM, 详 见 https://github.com/creationix/nvmo 
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参考 GitHub 上 NVM 的 文档 ， 比 如 使 用 curl 来 下 载 安装 脚本 : 
$ curl -o- https://raw.githubusercontent.com/creationix/nvm/vO.31.0/install.sh | bash 


你 在 安装 时 ， 请 参考 最 新 的 文档 。 接 着 ， 运 行 NVM 的 命令 来 安装 固定 版 本 的 Node.js 并 使 
用 它 ， 这 里 安装 Node 5.0 版 本 : 














# Install Node 
$ nvm install 5.0 


# Use Node 
$ nvm use 5.0 


然后 回 到 first-react-app 目录 下 ,我们 需要 新 建 一 个 Node.js 的 配置 文件 package.json。 这 里 
既 可 以 通过 npm init 交互 的 方式 来 新 建 ， 也 可 以 手动 新 建 。 下 面 是 新 建 好 的 package.json: 











{ 
"name": "first-react-app", 
"version": "0.0.1", 
"description": "first react app", 
"keywords": [ 
"react", 
"reactjs" 
]， 
"author": "react book group", 
"license": "MIT" 
} 





这 里 定义 了 项 目的 名 字 、 版 本 号 、 描 述 、 关 键 词 、 作 者 和 许可 协议 这 些 基 本 信息 。 对 于 每 一 
个 Node.js 项 目 来 说 ， 这 些 基本 信息 都 是 必 不 可 少 的 。 


如 果 这 个 项 目 需 要 上 传 到 Git 仓库 上 ， 那 么 需要 在 根 目 录 中 执行 git init 命令 初始 化 项 目 ， 
并 在 packagejson 中 增加 必要 的 信息 。 下 面 就 以 GitHub 为 例 来 介绍 : 


{ 
"repository": { 
"type": "git", 
"url": "https://github.com/arcthur/first-react-app.git" 
}, 
"bugs": { 
"url": "https://github.com/arcthur/first-react-app/issues" 
}, 
"homepage": "https://github.com/arcthur/first-react-app" 
} 


配置 信息 非常 直观 ， 对 应 的 是 仓库 配置 、bug 提交 地 址 以 及 项 目 主页 。 其 中 ， 这 里 项 目 主 页 
直接 使 用 了 仓库 的 主页 ， 当 然 也 可 以 使 用 如 独立 域名 的 主页 地 址 来 替代 。 
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A.2 ES6 编译 工具 : Babel 


早 些 年 , CoffeeScript 出 世 那 会 , 前 端 界 都 为 之 疯狂 。 近 年 来 , 前 端 界 对 于 新 标准 , 尤其 是 ES6 
的 讨论 越 来 越 多 。 历 时 近 6 年 时 间 制 定 的 新 标准 ECMAScript 6 终于 在 2015 年 6 月 正式 发 布 了 。 
ES6 从 草案 起 ， 就 以 集合 了 众多 新 语法 、 新 特性 吸引 了 无 数 开发 者 的 目光 ， 使 得 在 草案 期 ， 就 涌 
现 了 许多 特性 的 polyfill 实现 。 另 一 方面 ， 作 为 ECMAScript 的 新 标准 ， 各 大 浏览 需 的 兼容 程度 
实在 堪忧 。 而 前 端 界 为 JavaScript 这 门 语言 作 过 的 种 种 尝试 ( 包括 CoffeeScript )， 都 像 流星 一 样 
迅速 陨落 。 

工程 师 们 对 ES6 学 习 的 热情 和 迫切 想 要 在 开发 环境 中 使 用 的 心情 ,使 Babel、Tracur 等 ES6 编 
译 器 应 运 而 生 。 它 们 能 将 尚未 得 到 支持 的 ES6 特性 转换 为 ES5 标准 的 代码 ， 使 其 得 到 各 个 浏览 
器 的 支持 。 其 中 Babel 因为 Transformer 的 设计 特点 ， 获 得 了 许多 开发 者 的 青睐 。 

如 果 你 不 熟悉 ES6， 在 我 们 的 示例 代码 中 你 将 会 看 到 许多 陌生 的 语法 ， 比 如 箭头 函数 、 函 数 
默认 参数 等 。 使 用 ES6 语法 ， 不 仅 可 以 减少 大 量 的 元 余 代 码 ， 还 能 借助 新 的 关键 字 ( 如 const ) 
确保 程序 的 健壮 性 。 此 外 ， 新 的 特性 ( 如 promise 和 generator 等 )， 可 以 帮助 我 们 更 好 地 处 理 异 
步 事 务 。 

展开 ES6 会 有 非常 多 的 内 容 要 说 ， 推 荐 读者 去 阅读 ES6 的 相关 资料 和 文档 。 本 书 的 所 有 示 
例 代码 将 全 部 使 用 ES6 语法 来 实现 。 

接着 ， 我 们 通过 官网 提供 的 Try it out" 写 一 个 简单 的 示例 来 说 明 Babel 到 底 是 什么 : 


function quicksort(arr) { 
if (!arr.length) { 



































































































































return []; 

const [pivot, ...rest] = arr; 

return [ 
.. .quicksort(rest.filter(x => x < pivot)), 
pivot, 


.. .quicksort(rest.filter(x => x >= pivot)), 
J; 
} 


上 述 代码 是 经 典 的 快 排 算法 的 ES2015 实现 。 当 然 ， 如 果 你 还 不 熟悉 ES2015 的 语法 ， 那 么 
要 赶快 行动 起 来 。 现 在 ， 我 们 来 看 看 编译 后 的 结果 是 怎么 样 的 呢 ? 


"use strict"; 
































function quicksort(arr) { 
if (!arr.length) { 





GD Babel repl， 详 见 http://babeljs.io/repl/。 
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return []; 


} 


var pivot = arr[0]; 
var rest = arr.slice(1); 


return [J].concat(quicksort(rest.filter(function(x) { 
return x < pivot; 

})), [pivot], quicksort(rest.filter(function(x) { 
return x >= pivot; 


1))); 











文 么 看 代码 是 不 是 熟悉 了 很 多 , 编译 后 的 ES5 代码 可 以 在 绝 大 部 分 浏览 器 上 运行 。 当 然 , 我 
们 看 到 fitter 方法 在 一 些 低级 浏览 器 上 还 不 支持 ， 此 时 可 以 通过 加 入 Babel 的 potyfttt 来 支持 
它们 O 

SO ne en i i 
的 语法 ，1.2 节 介 绍 过 )， 这 真是 太 让 人 兴奋 了 。 我 们 看 看 它 是 怎么 编译 的 : 


import React, { Component } from 'react'; 
import ReactDOM from 'react-dom'; 





















































class HelloMessage extends Component { 
render() { 
return <div>Hello {this.props.name}</div>; 
} 
} 


ReactDOM. render(<Page />, document.getElementById('app')); 


这 里 的 import 和 class 关键 词 都 是 ES6 的 语法 ， 而 render 方法 中 return 的 标签 内 容 就 是 
JSX 语法 。 我 们 来 看 看 编译 后 的 代码 : 


// 这 里 省 略 _inherits 等 吕 数 的 定义 




















var HelloMessage = function (_Component) { 
_inherits(HelloMessage, _Component); 


function HelloMessage() { 
_CclassCallCheck(this, HelloMessage); 


return _possibleConstructorReturn(this, 
Object.getPrototypeOf(HelloMessage).apply(this, arguments)); 
} 


_CcreateClass(HelloMessage, [{ 
key: 'render', 
value: function render() { 
return _react2.defauLt.createELement( 
'div', 
null, 
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'Hello '， 
this.props.name 
); 
} 
}]); 


return HelloMessage; 
}(_react.Component); 


_reactDom2.default.render(_react2.default.createElement(Page, null), 

document .getELementById('app')); 

这 里 我 们 省 略 了 _createCtLass、_interopRequitreDefauLt 、_cLassCaLLCheck、_possibtLeCons- 
tructorReturn、_inherits 方法 的 实现 ， 如 果 你 感 兴趣 ， 可 以 通过 网 站 来 看 。 其 中 ，import 转换 
成 require 不 能 在 浏览 器 中 直接 使 用 ， 必 须 配 合 打包 工具 一 起 ， 之 后 介绍 的 webpack 就 可 以 让 浏 
览 器 支持 CommonJS 标准 的 代码 书写 与 打包 。 


到 此 ， 我 们 对 Babel 已 经 有 个 初步 的 认识 了 。 最 后 ， 回 归 正 题 ， 怎 么 在 工程 中 安装 Babel: 





$ npm install --save-dev babel-cli babel-core babel-polyfill babel-preset-es2015 babel-preset-react 


这 里 我 们 使 用 npm 包 管 理工 具 安 装 ， 其 中 babel-preset-es2015 和 babel-preset-react 可 以 理解 
为 我 们 选择 安装 了 两 个 套餐 ， 分 别 是 ES6 和 React 的 编译 插件 集 。 我 们 需要 在 项 目 中 新 建 一 
个 .babelrc 的 配置 文件 ， 这 个 文件 用 来 设置 不 同 环境 的 转 码 插件 ， 默 认 作用 域 是 所 有 环境 ， 你 也 
可 以 区 分 开发 环境 与 线 上 环境 。 现 在 我 们 把 需要 的 preset 加 入 到 配置 中 : 

{ 


presets: ["es2015", "react"] 


3 


你 还 可 以 单独 安装 其 他 的 preset 或 plugin。 比 如 需要 增加 transform-export-extensions 插件 ， 
那么 只 需要 使 用 npm iinstall --save-dev babel-plugin-transform-export-extensions 命令 ， 然 


后 更 改 .babelrc 文件 : 
{ 


plugins: ["transform-export-extensions"], 
presets: ["es2015", "react"] 
} 
此 外 ，Babel 也 支持 ES7 草案 的 一 些 特性 。 如 果 你 想 尝 斌 它们， 不妨 参考 官方 文档 ， 选 择 对 
应 的 preset 或 plugin 安装 。 


此 外 ，Babel 还 有 非常 多 好 玩 的 特性 ， 留 给 读者 去 探索 。 这 里 ， 我 们 对 于 Babel 的 配置 已 经 
完成 了 。 
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A.3 CSS 预 处 理 器 : Sass 


Sass 是 CSS 预 处 理 器 。CSS 预 处 理 器 是 一 种 由 CSS 扩展 而 来 的 语言 ， 用 于 为 CSS 增加 一 些 
编程 的 特性 。 因 为 编译 过 程 前 置 ， 所 以 无 需 考 虑 浏览 器 的 兼容 性 问题 。 例 如 ， 可 以 在 CSS 中 使 用 


变量 、 简 单 的 程序 逻辑 、 抑 数 等 基本 技巧 ， 让 你 的 CSS 更 加 简洁 ， 适 应 性 更 强 ， 代 但 更 直观 等 。 


我 们 在 应 用 中 更 多 使 用 SCSS， 它 是 Sass 3 引入 新 的 语法 ， 其 语法 完全 兼容 CSS3 ， 并 且 继 承 
了 Sass 的 强大 功能 。 后 续 我 们 都 使 用 SCSS 编码 。 


举 个 最 简单 的 例子 ， 我 们 使 用 变量 来 管理 公用 参数 : 










































































sfont-stack: Helvetica, sans-serif; 
$primary-color: #333; 


body { 
font: 100% $font-stack; 
color: S$primary-color; 


} 





上 述 SCSS 代码 封装 了 字体 配置 和 颜色 配置 ， 这 样 可 以 方便 样式 文件 中 不 同位 置 的 重用 。 代 
码 编译 后 : 


body { 
font: 100% Helvetica, sans-serif; 
color: #333; 

} 


另 一 个 常用 的 SCSS 特性 是 树 状 结构 代码 : 








nav { 
ulLf{ 
margin: 0; 
padding: 0; 
list-style: none; 


} 


LT 
display: inline-block; 
} 


alt 
display: block; 
padding: 6px 12px; 
text-decoration: none; 





} 
} 
上 述 代 码 编译 后 : 
nav UL { 


margin: 0; 
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padding: 0; 
list-style: none; 


} 


nav li { 
display: inline-block; 
} 


navaf{ 
display: block; 
padding: 6px 12px; 
text-decoration: none; 


} 

我 们 看 到 用 SCSS 之 后 ， 层 级 关系 清晰 地 显示 出 来 。 当 然 ，SCSS 还 有 诸如 mixin、 继 承 、 杨 
数 计算 等 好 多 特性 ， 这 里 就 不 一 一 介绍 了 。 要 想 学 习 更 多 SCSS 的 写法 ， 请 移 步 官网 "。 本 书 涉 
及 CSS 的 代码 都 使 用 SCSS 代码 来 编写 。 























A.4 测试 环境 : Karma 


前 端 测试 现在 也 越 来 越 重视 , 业界 现在 流传 着 一 句 话 : 谁 敢 用 没有 测试 代码 的 开源 包 。Karma 
是 测试 任务 管理 工具 , 用 来 帮助 开发 者 方便 地 进行 测试 。 而 在 前 端 开 发 中 , 主要 是 配合 静态 测试 
框架 来 做 单元 测试 。 

下 面 通过 npm 安装 Karma 环境 和 必要 的 包 : 
































$ npm install --save-dev karma karma-chai karma-chrome-Launcher karma-coverage karma-coveralls 
karma-mocha karma-sourcemap-loader karma-webpack istanbul-instrumenter-loader 


然后 ， 通 过 存放 在 目录 下 的 karma.confjs 配置 文件 来 启动 文件 : 


"use strict'; 




















var path = require('path'); 


module.exports = function(config) { 
if (process.env.RELEASE) { 
config.singleRun = true; 


} 
config.set({ 
basePath: '../', 
frameworks: ['mocha', 'chai'], 
files: [ 
{ pattern: 'test/index.js', included: true, watched: false }, 
]， 
exclude: [ 





GD Sass， 详 见 http://sass-lang.com/。 
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'test/coverage/**', 
'node_modules/'， 


]; 
preprocessors: { 
"test/index.js': ['webpack', 'sourcemap'], 
}, 
webpack: { 
devtool: 'inline-source-map', 
module: { 
noParse: [ 
/node_modules\/sinon\//, 
ls 
loaders: [{ 
test: /\.js$/, 
include: [ 
/src|test|recharts/, 
]， 
exclude: /node_modutLes/， 
Loader: 'babel', 
},{ 
test: /\.json$/, 
Loader: 'json', 
]]， 
postLoaders: [{ 
test: /\.js$/, 
include: /src/, 
exclude: /node_modules/, 
loader: 'istanbul-instrumenter', 
]]， 
}， 


externals: { 
'jsdom': 'window', 
'react/lib/ExecutionEnvironment': true， 
'react/lib/ReactContext': 'window', 
'text-encoding': 'window', 

]， 

resoLve: { 
alias: { 

'sinon': 'sinon/pkg/sinon', 
'recharts': path.resolve('./src/index.js'), 

) 

}， 

stats: { 
assets: false, 
colors: true, 
version: false, 
hash: false, 
timings: false, 
chunks: false, 
chunkModules: false, 

]， 

debug: false, 

】， 
plugins: [ 
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"karma-webpack ' ， 
"karma-mocha ' ， 
"karma-Ccoverage ' ， 
"karma-chai ' ， 
"karma-sourcemap-Loader ' ， 
"karma-chrome-Launcher ' ， 
'istanbul-instrumenter-loader', 
'karma-coveralls', 
]， 
reporters: ['progress', 'coverage', 'coveralls'], 
coverageReporter: { 
dir: 'test', 
reporters: [{ 
type: 'html', 
subdir: 'coverage', 
}, { 
type: 'text', 
}, { 
type: 'lcov', 
subdir: 'coverage', 
}] 
}， 
webpackMiddleware: { 
noInfo: true, 
}， 
port: 9876 ， 
colors: true， 
LogLeveL: config.LOG_INFO, 
browsers: ['Chrome'], 
browserNoActivityTimeout: 60000 ， 


]); 
}; 
然后 在 npm scripts 中 添加 脚本 : 
{ 
"scripts": { 
"test": "karma start test/karma.conf.js" 
} 
} 


最 后 ， 我 们 就 可 以 通过 npm run test 启动 测试 。 如 果 只 想 启动 一 个 单 例 ， 那 么 只 需要 在 命 
令 前 加 上 RELEASE=1 就 行 了 。 这 里 绑 定 的 是 Mocha 框架 , 测试 框架 大 同 小 异 ， 开 发 者 可 以 很 快 熟 
悉 API 进行 测试 代码 的 编写 。 

















A.5 工程 构建 工具 : webpack 
官网 对 webpack” 的 定义 是 模块 打包 (module bundler )， 它 的 目的 就 是 把 有 依赖 关系 的 各 种 



































GD webpack， 详 见 https://webpack.github.io。 
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文件 打包 成 一 系列 静态 资源 。 尽 管 业 界 在 之 前 就 推出 了 优秀 的 打包 工具 ， 如 Browserify ， 但 
webpack 的 迅速 崛起 ， 还 有 其 特别 之 处 : 


口 支持 所 有 主流 的 打包 标准 (CommonJS 、AMD 、UMD 、Globals ); 

口 可 以 通过 不 同 的 webpack loader， 支 持 打 包 css、scss 、json 、markdown 等 格式 的 文件 ; 

口 有 完善 的 缓存 破坏 / 散 列 ( cache busting/hashing ) 系统 ; 

口 内 置 热 重 载 功 能 ; 

口 有 一 系列 优化 方案 和 插件 机 制 来 满足 各 种 需求 ， 如 代码 切割 ( code splitting )。 

那么 , 你 可 能 会 问 : 还 需要 Grunt/Gulp 这 些 流程 控制 工具 吗 ? 我 的 答案 是 在 需要 的 场景 下 依 
然 可 以 使 用 它们 ， 虽 然 它们 已 经 有 些 过 时 了 。 现 在 业界 通用 的 方案 是 直接 利用 npm scripts 来 定 
义 项 目 内 置 脚本 。 


首先 ， 还 是 通过 npm 来 安装 webpack: 































































































$ npm install --save-dev webpack 


A.5.1 开发 环境 配置 


这 里 我 们 需要 的 是 本 地 启动 一 个 Web 服务 ,实现 监听 目录 变化 来 对 JSX 和 ES2015 代码 的 
编译 。 


首先 ， 需要 安装 webpack 配套 的 Web 服务 器 webpack-dev-server: 























npm install --save-dev webpack-dev-server 
这 是 一 个 基于 Express 的 小 型 文件 服务 器 ， 最 基本 的 功能 是 启动 http 服务 器 并 让 我 们 使 用 
HTTP 协议 访问 应 用 。 不 过 其 最 强大 的 功能 在 于 和 webpack 结合 提供 强大 的 热 模 块 替 换 功 能 。 


另外 , 需要 加 载 一 些 loader, 这 里 我 们 安装 了 编译 Sass 的 sass loader, 打包 样式 的 style 和 css 
loader，Babel 编译 的 loader，React 热 加 载 的 loader: 



































$ npm install --save-dev babel-loader sass-Loader style-loader css-Loader react-hot-Loader 
然后 配置 webpack 开发 环境 的 配置 文件 webpack.config.devjs, 并 将 其 存放 在 工程 的 根 目录 下 : 


var path = require('path'); 
var fs = require('fs'); 
var webpack = require('webpack'); 


module.exports = { 
devtool: 'cheap-module-eval-source-map', 
entry: { 
app: [ 
'webpack-hot-middleware/client', 
'./src/app', 
]， 


附录 A 开发 环境 339 





vendors: ['react', 'react-dom', 'react-router'], 


}s 


output: { 
filename: '[name].js', 
publicpath: '/static/', 


}, 
module: { 
loaders: [{ 
test: /\.jsx?$/, 
include: [ 
path.resolve(__dirname, 'src'), 
]， 
Loaders: ['react-hot', 'babel'], 
二 : 渤 
test: /\.scss$/, 
include: [ 
path.resolve(__dirname, 'src'), 
] 
loader: 'style!css!sass?sourceMap=true&sourceMapContents=true', 
}]， 
}, 
resolve: { 
extensions: ['', '.js', '.jsx', '.scss', '.css'], 
}, 
plugins: [ 


new webpack.optimize.CommonsChunkPlugin('vendors', 'vendors.js'), 

new webpack.optimize.DedupePlugin(), 

new webpack.Defineplugin({ 
"process.env.NODE_ENV' : JSON.stringify(process.env.NODE_ENV), 
_ DEV__: true， 

])， 

new webpack.NoErrorsPLugin() ， 

new webpack.HotModuLeRepLacementPLugin() ， 

]， 
}; 


我 们 写 了 一 个 通用 的 启动 配置 ， 接 着 通过 webpack-dev-server 来 启动 开发 环境 的 服务 。 但 在 
实际 项 目 中 ， 我 们 常常 会 封装 一 些 配 置 。 因 此 ， 在 根 目 录 下 再 新 建文 件 serverjs: 

var path = require('path'); 

var express = require('express'); 


var webpack = require('webpack'); 
var config = require('./webpack.config.dev'); 




















var app = express(); 
var compiler = webpack(config); 


var webpackDevOptions = { 
noInfo: true, 
historyApiFallback: true, 


340 附录 A 开发 环境 





publicpath: config.output.publicpath, 
headers: { 
'Access-Control-Allow-Origin': '*', 
}; 
}; 


app.use(require('webpack-dev-middleware')(compiler, webpackDevOptions)); 
app.use(require('webpack-hot-middleware')(compiler)); 


app.get('*', function(req, res) { 
res.sendFile(path.join(__dirname, 'index.html')); 


]); 
app.Listen(8787， 'localhost', function(err) { 
if (err) { 
console.log(err); 
return; 
} 


console.log('Listening at http://\localhost:8787'); 
]); 


serverjs 是 一 个 非常 简单 的 Node.js Web 服务 器 ， 使 用 的 是 Express 这 个 框架 ， 它 可 以 很 方便 
地 集成 middleware。 可 以 看 到 ， 这 里 集成 了 两 个 middleware， 分 别 用 于 集成 webpack 的 开发 环境 
与 热 重 载 的 模块 。 最 后 ， 通 过 Express 的 8787 端口 来 开启 服务 器 。 


其 中 ， 我 们 看 到 服务 使 用 的 HTML 模板 其 实 是 预 设 的 index.html。 当 然 ， 我 们 需要 在 根 目录 
里 存放 这 个 文件 : 


<!DOCTYPE htmL> 
<html> 
<head> 
<meta charset="UTF-8" /> 
<title>First React App</title> 
</head> 
<body> 
<div id="app"></div> 
<script src="/static/vendors.js"></script> 
<script src="/static/app.js"></script> 
</body> 
</html> 


这 时 候 , 已 经 配置 完 开 发 环境 了 ,我 们 需要 为 启动 它 写 一 个 npm scripts。 在 package.json 的 
scripts 项 中 配置 启动 需要 的 命令 
{ 
"scripts": { 
"start": "node server.js" 


} 
} 


当 需 要 使 用 开发 环境 的 时 候 ， 只 需要 在 shell 中 执行 npm run start 命令 即 可 。 
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A.5.2” 线 上 环境 配置 


线 上 环境 与 开发 环境 最 大 的 不 同 是 , 我 们 是 否 需 要 打包 成 文件 存放 起 来 , 或 上 传 到 CDN 上 ， 
或 上 传 到 npm 仓库 上 。 


根据 线 上 环境 的 需要 ， 我 们 先 安装 必要 的 npm 包 : 




















$ npm install --save-dev postcss cssnano extract-text-webpack-plugin postcss-Loader 


同样 来 配置 webpack 配置 文件 webpack.config.prod.js， 并 将 其 存放 在 工程 的 根 目 录 下 : 





var path = require('path'); 

var fs = require('fs'); 

var webpack = require('webpack'); 

var ExtractTextPLugin = require('extract-text-webpack-plugin'); 
var Cssnano = require('cssnano'); 


module.exports = { 
devtool: 'source-map', 
entry: { 
app: ['./src/app'], 
vendors: ['react', 'react-dom', 'react-router'], 


}, 


output: { 
path: path.resolve(__dirname, 'build'), 
filename: '[name].js', 


}， 
module: { 
loaders: [{ 
test: /\.jsx?$/, 
include: [ 
path.resolve(__dirname, 'src'), 
]， 
Loaders: ['babel'], 
}, { 
test: /\.scss$/, 
include: [ 
path.resolve(__dirname, 'src'), 
]， 
loader: ExtractTextPlugin.extract('style-loader', 'css!postcss!sass'), 
]] ， 
】， 
postcss: [ 
cssnano({ 


sourcemap: true, 
autoprefixer: { 
add: true, 
remove: true, 
browsers: ['last 2 version', 'Chrome 31', 'Safari 8'], 


}, 
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discardComments: { 
removeAll: true, 
}， 
])， 
] ， 


resoLve: { 
extensions: ['', '.js', '.jsx', '.scss', '.css'], 


ye 


plugins: [ 
new webpack.optimize.CommonsChunkPlugin('vendors', 'vendors.js'), 
new webpack.optimize.DedupePlugin(), 
new webpack.Defineplugin({ 
'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV), 
_DEV__: false, 
])， 
new ExtractTextPlugin('style.css', { 
aLLChunks: true， 
])， 
new webpack .optimize.UgLifyJsPLugin({ 
Compress: { 
unused: true， 
dead_code: true， 














}, 
])， 
]， 
}; 
这 时 已 经 配置 完 环境 , 现在 需要 启动 它 , 在 package.json 的 scripts 项 中 配置 启动 需要 的 命令 : 
{ 
"scripts": { 
"clean": "rimraf build", 
"build:webpack": "NODE_ENV=production webpack --config webpack.config.prod.js", 
"build": "npm run clean && npm run build:webpack" 
} 
} 


当 执 行 npm run butLd 时 ， 就 会 打包 并 压缩 文件 到 build 目录 下 。 此 时 ， 我 们 想到 build 目录 
其 实 没 必要 上 传 到 Git 仓库 上 ， 为 此 我 们 增加 .gitignore 文件 并 配置 忽略 build 目录 。 


如 果 这 个 项 目 需要 当成 模块 发 布 到 npm 仓库 上 ， 就 需要 在 package.json 里 额外 配置 输出 参数 : 


{ 
"main": "build/app.js", 
"jsnext:main": "src/app.js" 


} 
其 中 main 指 的 是 入 口 文件 ， 这 里 就 是 编译 好 的 build 目录 下 的 app.js 文件 。 那 么 jsnext:main 指 
的 是 什么 呢 ? 它 是 兼容 rollup 构建 工具 读 取 入 口 文件 的 参数 。Rollup 与 webpack 都 是 前 端 项 目 构 
建 工 具 ， 但 不 同 的 是 rollup 是 基于 下 一 代 ES6 模块 化 的 构建 ，tree-shaking 是 它 最 大 的 亮点 。 还 
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未 发 布 的 webpack 2.0 版 本 同样 具备 tree-shaking 特性 。 


这 几 年 ,构建 工具 不 断 推 陈 出 新 ， 也 从 侧面 反应 了 前 端 界 欣 欣 向 荣 , 今天 的 webpack 也 许 用 
不 了 多 入 就 会 被 更 厉害 的 工具 代替 ， 比 如 最 近 发 布 的 rollup。 但 不 变 的 是 我 们 所 需要 的 功能 
合并 、 打 包 、 压 缩 ， 不同 的 是 越 来 越 “ 向 前 看 ”和 “便捷 ”"。 对 于 工具 ， 前 端 工程 也 许 有 标准 化 
的 一 天 ， 而 这 之 前 我 们 无 法 评论 这 些 工具 的 不 断 出 现 是 好 或 是 不 好 。 只 有 当前 是 否 合适 , 合适 的 
就 是 最 好 的 。 




































































A.6 安装 React 环境 
我 们 终于 可 以 开始 开发 了 : 


$ npm install --save react react-dom 
至 此 ， 我 们 的 package.json 已 经 基本 上 成 型 了 。 在 配置 文件 中 简单 修改 一 下 React 的 版 本 
{ 


"peerDependencies": { 
"react": "^0.14.0 || ^15.0.0", 
"react-dom": "^0.14.0 || ^15.0.0" 
}, 
"dependencies": { 
"react": "^15.0.0", 
"react-dom": "^15.0.0" 
} 
} 


接着 ， 写 一 个 简单 的 React 组 件 ， 并 把 这 个 组 件 保存 在 src/app.js 中 : 





import React from 'react'; 
import ReactDOM from 'react-dom'; 


function Page() { 
const topics = ['React', 'Flux', 'Redux'] 


return ( 
<div> 
<h1>React Book Title</h1i> 
<UL> 
{topics.map(topic => (<li>{topic}</li>))} 
</ul> 
</div> 
); 
} 


ReactDOM. render(<Page />, document.getElementById('app')); 


到 这 里 ,我 们 需要 增加 测试 来 确保 项 目的 泻 染 结果 





O 





344 ”附录 A 开发 环境 





这 个 例子 最 终 展 示 了 一 段 无 序列 表 的 信息 。 

当 启动 开发 环境 命令 npm run start 后 ， 生 成 了 URL: http://localhost:8787/index.html。 在 浏 
览 絮 中 打开 该 URL， 即 可 查看 页 面 效 果 。 

当 我 们 开发 了 一 定 功 能 后 ， 就 需要 commit 并 上 传 到 服务 器 上 ， 此 时 可 以 运行 相应 的 git 命 
令 来 完成 。 

最 后 ， 就 需要 发 布 版 本 了 ， 此 时 可 以 通过 执行 命令 npm run build 合并 压缩 打包 文件 ， 再 执 
行 npm publish 命令 发 布 到 远程 npm 仓库 上 。 

现在 ， 我 们 可 以 在 应 用 中 执行 npm install 命令 下 载 包 了 。 

















A.7 小 结 


本 附录 提 到 了 一 些 React 项 目 实践 中 用 到 的 工具 ， 比 如 postcss， 不 在 本 书 的 讨论 范围 内 ， 但 
它们 确实 是 在 开发 中 非常 实用 的 工具 ， 和 希望 读者 可 以 进一步 去 了 解 它们 。 

至 此 ， 我 们 已 经 对 React 的 开发 环境 有 了 大 致 的 了 解 。 当 然 ， 在 日 常 开发 中 ， 我 们 还 会 增加 
代码 检查 ( ESLint )、 编译 器 配置 (EditorConfig ) 等 插件 去 规范 开发 过 程 , 这 些 内 容 将 在 附录 B 中 
详 述 。 

在 业界 ，React 或 是 Redux 初始 化 项 目 中 已 经 有 很 多 实践 ， 较 为 有 名 的 是 React Boilerplate”。 
不 过 ,正如 开篇 所 说 ,工具 一 直 在 变化 , 但 本 质 都 是 一 样 的 。 在 生产 环境 中 的 实践 是 每 一 位 开发 
人 员 都 需要 不 断 尝 试 的 。 

































































GD React Boilerplate， 详 见 https://github.com/mxstbr/react-boilerplate。 


编码 规范 











在 团队 开发 中 , 编码 规范 至 关 重 要 ,一 份 统一 的 编码 规范 可 以 大 大 降低 阅读 代码 的 成 本 。 近 
年 来 ， 前 端 业界 对 编码 规范 的 自动 化 工具 也 做 了 不 少 实践 ， 从 最 早 的 JSLint， 到 之 后 的 JSHint， 
再 到 今天 的 ESLint。 本 附录 中 ， 我 们 主要 讲述 ESLint 的 用 法 。 


B.1 使 用 ESLint 
ESLint 由 Nicholas C. Zakas 编写 。 目 标 是 以 可 扩展 、 每 条 规则 独立 、 不 内 置 编码 风格 为 理念 
编写 一 个 Lint 工具 。 用 户 可 以 定制 自己 的 规则 作成 公共 包 。 
ESLint 主要 有 以 下 特点 : 
口 默认 规则 包含 所 有 JSLint、JSHint 中 存在 的 规则 ， 易 迁移 ; 
口 规则 可 配置 性 高 ， 可 设置 “警告 ”“ 错 误 ” 两 个 error 等 级 ， 或 者 直接 禁用 ; 
口 包含 代码 风格 检测 的 规则 ; 
口 支持 插件 扩展 、 自 定义 规则 。 
针对 React 开发 者 ，ESLint 已 经 可 以 很 好 地 支持 JSX 语法 。 


我 们 从 React 应 用 中 怎么 配置 开始 说 起 。 首 先 ， 通 过 npm 来 安装 必要 的 包 : 
















































































$ npm install --save-dev babel-eslint eslint eslint-plugin-react 


babel-eslint 让 ESLint 用 Babel 作为 解释 髓 ，eslint-plugin-react i 上 ESLint 支持 React 语法。 然 
后 ,在 package.json 里 配置 对 应 的 scripts， 假设 我 们 对 src 和 test 目录 作 检 查 : 








"scripts": { 
"lint": "eslint src test" 


} 


ESLint 的 配置 写 在 根 目录 下 。 新 建 配 置 文 件 .eslintrc， 如 果子 目录 也 包含 .eslintrc， 则 子 目 录 
会 忽略 根 日 录 的 配置 文件 。 这 种 设置 方式 便于 在 不 同 环境 下 使 用 不 同 的 配置 。 相 关 代 码 如 下 : 





























€ 


"extends": "eslint:recommended", 
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"ecmaFeatures": { 
"jsx": true, 
"modules": true 

}, 

"env": { 
"browser": true, 
"node": true, 


"es6": true 
}; 
"parser": "babel-eslint", 
"rules": { 


"strict": 0， 
"valid-jsdoc": 2， 


"react/jsx-uses-react": 2， 
"react/jsx-uses-vars": 2， 
"react/react-in-jsx-scope": 2 

}, 

"plugins": [ 
"react" 

] 

小 


其 中 ，plugins 处 配置 了 react， 即 加 入 了 自 定 义 规则 ， 这 也 是 ESLint 最 核心 的 功能 之 一 。 
此 外 ， 我 们 也 可 以 在 文件 内 配置 特别 的 配置 。 
禁用 ESLint， 比 如 : 











/* eslint-disable */ 
const obj = { 

key: 'value', 
}; 


/* eslint-enable */ 


禁用 一 条 Lint， 比 如 : 





/* eslint-disable no-console */ 
console. log( 'test'); 
/* eslint-enable no-console */ 


调整 Eslint 规则 ， 比 如 : 


/* eslint no-console: "error" */ 
console. log( 'test'); 


ESLint 还 有 一 个 参数 extends ， 相 当 我 们 的 配置 继承 于 它 。 在 上 述 配 置 中 ， 我们 写 的 是 
esLint:recommended， 这 是 内 置 的 配置 。 我 们 之 后 自 定义 的 配置 就 继承 于 它 。 这 里 ， 推 荐 开发 者 
使 用 Airbnb 定制 的 JavaScript 规范 写法 "， 整 套 规 范 推荐 了 ES6 的 语法 ， 是 整个 前 端 业 界 最 火 也 
是 比较 公认 的 方案 。 由 它 的 规范 写成 的 公共 配置 是 eslint-config-airbnb。 我 们 可 以 通过 npm 安装 





































































































Q@ JavaScript Style Guide， 详 见 https://github.com/airbnb/javascript。 
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它 ， 并 在 自己 的 ESLint config 中 将 Airbnb 的 配置 设置 成 基础 配置 。 


最 后 ，.eslintrc 可 以 写成 如 下 形式 : 
{ 


"extends": "eslint-config-airbnb", 
"ecmaFeatures": { 
"jsx": true， 
"modules": true 
}， 
"env": { 
"browser": true, 
"node": true, 





"es6": true 
}， 
"parser": "babel-eslint", 
"rules": { 


"strict": 0， 
"valid-jsdoc": 2， 


"react/jsx-uses-react": 2， 
"react/jsx-uses-vars": 2， 
"react/react-in-jsx-scope": 2 

} 

"plugins": [ 
"react" 

] 

} 


B.2 使 用 EditorConfig 

















前 面 讲 到 的 是 前 端 开发 时 的 规范 化 , 现在 





























的 EditorConfig 是 对 编辑 器 的 规范 化 。 众 所 周知 ， 














前 端 工程 师 会 使 用 各 种 不 同 的 编辑 器 开发 脚本 ， 从 早期 的 Notepad++、Vim 到 今天 的 Atom、 
Sublime 等 编辑 咒 。 编 辑 器 的 发 展 与 前 端 一 样 ， 非 常 迅速 。 然 而 对 于 不 同 的 系统 ， 我 们 同样 希望 








规范 好 开发 时 编辑 器 的 基础 配置 。 从 某 种 程度 上 说 ，EditorConfig 的 目的 是 让 工程 里 的 代码 像 是 




















在 同一 个 编辑 需 打 开 的 。 























EditorConfig 的 配置 放 在 根 目录 下 保存 为 .editorconfig: 





root = true 


[*] 

end_of_line = lf 

charset = utf-8 

trim trailing whitespace = true 
insert_finaL_newLine = true 
indent_style = space 

indent_ size = 2 
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从 键 值 中 我 们 很 容易 知道 常用 的 配置 信息 ， 比 如 缩 进 风格 是 空格 ， 缩 进 量 是 2 个 空格 等 。 

之 后 ， 我 们 用 什么 编辑 器 ， 就 去 下 载 相应 的 EditorConfig 插件 。 几 乎 主流 的 编辑 器 都 支持 。 
但 现在 EditorConfig 配置 非常 少 ， 只 局 限于 基本 的 文件 缩 进 、 换 行 等 格式 ， 虽 然 这 些 也 可 以 在 
ESLint 里 配置 ， 但 从 编辑 器 层面 去 做 这 件 事 会 变 得 智能 很 多 ， 建 议 在 项 目 中 使 用 。 



































B.3 小 结 


前 端 发 展 到 今天 ,工程 化 的 体 量 越 来 越 重 。 我 们 也 需要 慢 慢 完善 前 端 体 系 ,让 团队 开发 更 容 
易 ， 项目 维护 更 容易 。 


Koa milddleware 














Koa 是 用 Node.js 实现 的 Web 服务 框架 。 在 Koa 中 ，middleware 的 使 用 场景 是 在 请 求 到 来 和 





发 送 响 应 之 间 ， 对 代码 按 功 能 进行 插件 化 管理 。 其 实现 方式 与 Redux 相近 ， 都 采用 了 函数 式 编程 
的 compose 方式 对 middleware 进行 组 合 ， 不 同 的 是 Koa 利用 了 ES6 的 generator” 来 实现 


middleware， 并 用 co 库 对 middleware 执行 的 流程 进行 管理 。 


C.1 



































generator 


Koa 中 的 middleware 其 实 就 是 一 个 generator 函数 ， 我 们 先 来 看 一 个 例子 : 


function* generatorFunc() { 
console.log('123'); 
yield 'stop'; 
console.log('456'); 
yield 'stop again'; 
console.log('789'); 
return 'finish'; 


} 


let gen = generatorFunc(); 
console.log(gen.next()); 

// 123 

// {"value":"stop","done":false} 
console.log(gen.next()); 

// 456 

// {"value":"stop again","done":false} 
console.log(gen.next()); 

// 789 

// {"value":"finish","done":true} 





generator 函数 和 一 般 函 数 的 区 别 在 于 函数 调 月 











有 后 并 不 立即 执行 , 返回 一 个 generator, 每 当 调 


用 generator 的 next() 方法 时 ， 郴 数 就 从 当前 位 置 执行 到 下 一 个 yield 位 置 ， 并 返回 yield 后 面 


的 内 容 。yield 后 面 可 以 是 普通 对 象 ，promise 、thunk 函数 ， 或 者 generator。 





GD ES6 Generators， 详 见 https://davidwalsh.name/es6-generators。 
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C.2 middleware 原理 分 析 


要 实现 一 套 middleware， 主 要 分 为 3 步 : 第 一 步 搜 集 middleware; 第 二 步 组 合 middleware; 
第 三 步调 用 执行 。Redux 中 ， 前 两 步 都 是 由 applymiddleware 实现 的 ， 调 用 执行 和 一 般 的 函数 调 
用 没有 什么 区 别 。Koa 中 搜集 middleware 的 工作 是 由 接口 app.use 实现 的 ， 方式 如 下 : 


var koa 
var app 




















= require('koa'); 

= koa(); 

app.use(function *read(next) { 
yield readFile('./a.text'); 
yield next; 
console.log('log end!'); 


}); 


app.use(function *logger(next) { 
console.log('log start!'); 
yield next; 
console.log('log end!'); 


]); 


app.use(function *response() { 
this.body = 'Hello World'; 
]); 


app.Listen(3000) ; 
app.use() 方法 将 所 有 generator 函数 保存 到 了 this.middleware 数组 里 : 


app.use = function(fn) { 





this.middleware.push(fn); 


}; 


Koa 组 合 middleware 的 方式 也 使 用 了 compose 方法 。 在 调用 app.Listen(3000) 的 时 候 ，Koa 
对 所 有 的 generator 函数 做 了 compose 处 理 : 
function compose(middleware) { 


return function *(next) { 
var i = middleware.length; 





var prev = next || noop(); 
var curr; 
while (i--) { 

curr = middleware[i]; 


prev 


} 


curr.call(this, prev); 


yield *prev; 
} 
直 
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compose 国 数 做 的 工作 是 : 


口 执行 所 有 generator 函数 ， 得 到 generator; 

口 将 generator 作为 下 一 次 generator 函数 执行 的 参数 next ; 
口 返回 一 个 和 人口 generator。 

执行 compose 后 的 效果 如 图 C-1 所 示 。 

generator 1 


enerator 2 
yield *prev; console. log('..'); 2 
yield next; generator 3 


console. log('..'); yield readFile(); 


















yield next; 
yield dowWhatever; 


‘ 3 


7 也 





图 C-1 Koa middleware 执行 compose 后 的 效 开 


最 后 ，co 做 的 事 就 是 让 代码 按 图 中 的 流程 走 起 来 。 图 C-2 说 明了 co 是 如 何 管理 


generator function 


yield(async)) 
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Koa-compose 
压缩 为 一 个 
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Middleware. 
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promise.all 









Middleware 
generator function 





yield 






图 C-2 co 是 如 何 管理 流程 的 








co 不 断 调用 gen.next() 方法 ， 如 果 yield 遇 到 非 generator 对 象 ， 则 将 其 包 庄 在 promise 里 ， 
等 待 其 完成 触发 resolve， 然 后 继续 在 当前 generator 里 执行 下 去 ; 如 果 yield 遇 到 新 generator 对 
象 ， 则 开启 一 个 新 的 co， 调 用 新 generator 的 next 方 法 ， 这 是 递归 。 另 外 ，co 本身 返回 的 也 是 一 
个 promise 对 象 , 所 以 不 管 yield 遇 到 的 是 新 generator 还 是 其 他 ,当前 co 都 会 停 下 来 等 待 其 完成 ， 
然后 继续 执行 gen.next()。 

无 论 是 Redux 还 是 Koa， 它 们 的 核心 思想 都 在 于 将 middleware 进行 组 合 ， 将 当前 middleware 
执行 一 遍 作 为 参数 传 给 下 一 个 middleware 去 执行 。 只 是 Redux 的 middleware 是 currying 函数 ， 执 
行 结果 是 一 个 匿名 函数 ; 而 Koa 的 middleware 是 一 个 generator 困 数 ， 执 行 完 后 是 一 个 generator。 
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